Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp242825pxb; Fri, 15 Jan 2021 02:02:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzIP1UVuCBz9NL8lW//c5GtMNJbwXxyddzoAogqOFKNiUTGpQVKGk+kuK1K+yjKXNKfUW1i X-Received: by 2002:a05:6402:1f4:: with SMTP id i20mr7140518edy.180.1610704931274; Fri, 15 Jan 2021 02:02:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610704931; cv=none; d=google.com; s=arc-20160816; b=0XClN0DbvjXZFXQhFkG4GE97Kg0w8U7r+H3/ezBNsMjHbgnD7ZoyIkJ6AyUvw8EHDS ELAhKG8tt4HF9+hFYVBy1yKtFq7b2VuPixfD+M2aqx7XL+SFAmwbA6kemokFoG4xvbwJ j++QBDRmA1t4I8ZKZjL4yLBt6hIkJXgX4CIwUV+KH0zf82/RMdnaRUVxBlSO6GkBzi9f Q8lT+IWSTpiVLBUVnAF8oo+91lIlrA3c5H3KLHu+zD5TCSmuCDAl7mVGlr7ecOgIImgS nnnYpclns+SClP10uwbhvuTFcIXlhXVgxetanP64uxOB8D1sxaNGLKTAOIAu/CmEE750 Z/Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=pQJUbSnglx6jrVEG/uzEMF/4a7MagxWfC490ZSlRcXE=; b=rJj7/Xk4TlTyjmrAE6KTSCcfYESkW2i3ZKaclTTebpzFK0IE1hvN4BO+A8UGSafgAD mvrVqXsGgnesIe8aHwyXcUa9cEg1PREEuxIgEUBD3DKUQ6U2BuH5hYH1gukYUI5/chvR CBa4e9wsLtphzeCubhmellFX7OXWAhv0Q/uKm6rLv9mz8v11rmr9Sc8AhGwItju3Xo8D CZGc66cHoi6kyrrRp+64jrPiUXTgIWAKLCxVXiRmMp9z6x9dG1pa3nhG4/imHU8p3Ycs ykxpu9eIf3uZkGQvdbmv3FkN1Ie90sht1nkBR4M31kebQDvytBWHSIg9U+EjvzFuNRf5 GqLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gerhold.net header.s=strato-dkim-0002 header.b=LwuonCwl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h13si3669727ejx.477.2021.01.15.02.01.46; Fri, 15 Jan 2021 02:02:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gerhold.net header.s=strato-dkim-0002 header.b=LwuonCwl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731094AbhAOJ7q (ORCPT + 99 others); Fri, 15 Jan 2021 04:59:46 -0500 Received: from mo4-p00-ob.smtp.rzone.de ([85.215.255.22]:29326 "EHLO mo4-p00-ob.smtp.rzone.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730981AbhAOJ7p (ORCPT ); Fri, 15 Jan 2021 04:59:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1610704548; s=strato-dkim-0002; d=gerhold.net; h=In-Reply-To:References:Message-ID:Subject:Cc:To:From:Date:From: Subject:Sender; bh=pQJUbSnglx6jrVEG/uzEMF/4a7MagxWfC490ZSlRcXE=; b=LwuonCwlR5oQhAfMTVYCA+JEmLvVXaqVXdgdKFVLwYPh64ilEne0HgAhbl/S7QuBfx ajFniRu/GLR+r+okpTTJoRNMDO5zGcGm2RH2V814PVJtEztXS2Im5Z2e+V3RKA7GpqTe FydKth6WxVV7H9fK3sn+G+GovvmumSnor+UDKoIp7ziG0W7EMddYeiLc40lG0lCADgHy Aqk8JwBkPSbkuZq16s1kdwO9RwM6wzVuJTdFl/YnMWigMwB1cOcJp0RiIuo4I/V0X5Fc fCQ7ZvwQd/wce3c97NW+QRmwL5AW64ANEA+y1n7AevmjzMQMny5ZYQVgLFJYSMwHrKfs Iqbg== X-RZG-AUTH: ":P3gBZUipdd93FF5ZZvYFPugejmSTVR2nRPhVOQ/OcYgojyw4j34+u26zEodhPgRDZ8j4IcrHBg==" X-RZG-CLASS-ID: mo00 Received: from gerhold.net by smtp.strato.de (RZmta 47.12.1 DYNA|AUTH) with ESMTPSA id R0a218x0F9tmpP8 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Fri, 15 Jan 2021 10:55:48 +0100 (CET) Date: Fri, 15 Jan 2021 10:55:46 +0100 From: Stephan Gerhold To: Saravana Kannan , "Rafael J. Wysocki" Cc: Greg Kroah-Hartman , LKML , Linux PM Subject: Re: [PATCH] driver core: Extend device_is_dependent() Message-ID: References: <2073294.4OfjquceTg@kreacher> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On Thu, Jan 14, 2021 at 11:31:12AM -0800, Saravana Kannan wrote: > On Thu, Jan 14, 2021 at 10:41 AM Rafael J. Wysocki wrote: > > > > From: Rafael J. Wysocki > > > > When adding a new device link, device_is_dependent() is used to > > check whether or not the prospective supplier device does not > > depend on the prospective consumer one to avoid adding loops > > to the graph of device dependencies. > > > > However, device_is_dependent() does not take the ancestors of > > the target device into account, so it may not detect an existing > > reverse dependency if, for example, the parent of the target > > device depends on the device passed as its first argument. > > > > For this reason, extend device_is_dependent() to also check if > > the device passed as its first argument is an ancestor of the > > target one and return 1 if that is the case. > > > > Signed-off-by: Rafael J. Wysocki > > Reported-by: Stephan Gerhold > > --- > > drivers/base/core.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > Index: linux-pm/drivers/base/core.c > > =================================================================== > > --- linux-pm.orig/drivers/base/core.c > > +++ linux-pm/drivers/base/core.c > > @@ -208,6 +208,16 @@ int device_links_read_lock_held(void) > > #endif > > #endif /* !CONFIG_SRCU */ > > > > +static bool device_is_ancestor(struct device *dev, struct device *target) > > +{ > > + while (target->parent) { > > + target = target->parent; > > + if (dev == target) > > + return true; > > + } > > + return false; > > +} > > + > > /** > > * device_is_dependent - Check if one device depends on another one > > * @dev: Device to check dependencies for. > > @@ -221,7 +231,7 @@ int device_is_dependent(struct device *d > > struct device_link *link; > > int ret; > > > > - if (dev == target) > > + if (dev == target || device_is_ancestor(dev, target)) > > return 1; > > > > ret = device_for_each_child(dev, target, device_is_dependent); > > > Thanks for the patch, Rafael! I tested it and it seems to avoid the circular device link (and therefore also the crash). FWIW: Tested-by: Stephan Gerhold > The code works, but it's not at all obvious what it's doing. Because, > at first glance, it's easy to mistakenly think that it's trying to > catch this case: > dev <- child1 <- child2 <- target > Isn't this pretty much the case we are trying to catch? I have: 78d9000.usb <- ci_hdrc.0 <- ci_hdrc.0.ulpi <- phy-ci_hdrc.0.ulpi.0 then something attempts to create a device link with consumer = 78d9000.usb, supplier = phy-ci_hdrc.0.ulpi.0, and to check if that is allowed we call device_is_dependent() with dev = 78d9000.usb, target = phy-ci_hdrc.0.ulpi.0. Note that this case would normally be covered by the device_for_each_child(). It's not in this case because the klist_children of 78d9000.usb is updated too late. > Maybe it's clearer if we do this check inside the loop? Something like: > > if (link->consumer == target || > device_is_ancestor(link->consumer, target)) > return 1; > I tried to test this with the diff below (let me know if I got it wrong). It does not seem to make any difference though, the circular device link is still created and without the reorder commit reverted it crashes. Thanks! Stephan diff --git a/drivers/base/core.c b/drivers/base/core.c index 14f165816742..7af4ef5f89e7 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -208,6 +208,16 @@ int device_links_read_lock_held(void) #endif #endif /* !CONFIG_SRCU */ +static bool device_is_ancestor(struct device *dev, struct device *target) +{ + while (target->parent) { + target = target->parent; + if (dev == target) + return true; + } + return false; +} + /** * device_is_dependent - Check if one device depends on another one * @dev: Device to check dependencies for. @@ -232,7 +242,7 @@ int device_is_dependent(struct device *dev, void *target) if (link->flags == (DL_FLAG_SYNC_STATE_ONLY | DL_FLAG_MANAGED)) continue; - if (link->consumer == target) + if (link->consumer == target || device_is_ancestor(link->consumer, target)) return 1; ret = device_is_dependent(link->consumer, target);