Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp28821pxb; Fri, 15 Jan 2021 05:06:04 -0800 (PST) X-Google-Smtp-Source: ABdhPJxioDMCAzmDGkRHbzcrkBpqfUIZZIttAxvB3jsBNqKp953z3b4rFzsNk1lpkS3ftPH9YMBC X-Received: by 2002:a17:906:39d0:: with SMTP id i16mr2446822eje.18.1610715964479; Fri, 15 Jan 2021 05:06:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610715964; cv=none; d=google.com; s=arc-20160816; b=ayS1A1IuUCY6iXYdLVevVYTwl+OZZfdBZkBHZDZGpr57qboalftdXMDBWGm6Wclt4e 5A5IwiuVr3kRFVjBqAFaGqu3juRfRYQJ6Uvkzy99FSutronCBV2aRHbkQVC8G/HmhzuG olvzWy0SBNwr5EPELdLscOSHZIEyR/7wwylj7Ur24/KBs2qVqh3pamTgPbVaMzEUEf2m 2h0eT2hqUdBWZbjhiIcIq8Zm/HEjfTNMww4SFrCeQXPpOlDL9GJhgZOjK9Dz2x9eja7X xSTXA0M/ITeJQ8Jvw9O+ILdiUyMbHGckDqGqASN4teO61l0OGc3y1J2SZYvj7LCYZQ4k QwjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version; bh=BfjWETeidop360v2z5Os9N6k2FYG3GkdQgvxI2qXOp8=; b=gyxRXAM6nO3yBQQic+fUkogtrRsN37Y0U91GkXM2q+kMl5ngDRar0IkXWxN+0gtSzv f89qOWjFK0U584eG0ZPvZ5yq1Nn9F88H7ZEP/WN9x537DK20ZB47mLMgRpTdWZ30y0ld rmW8/T9F9bGLle0ICHMV8zeuQuAR5raH4HJd6EQWMhMvdeg8zkHrIKY+aujGSIU1pwYD b1ib4N3J6XfqnXDAGKw0RCLaoz7u4MLctSen38SjmRB/4Sv528NcRks2kdvGBh80ftib 8W2gQDnpNnT31fOMe2K0EUyLCOQSloqWfHm/ZyzMSHUv8BWUO+Fmeq9zud86YK18eGbI vcLw== ARC-Authentication-Results: i=1; mx.google.com; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e8si566623edn.494.2021.01.15.05.05.40; Fri, 15 Jan 2021 05:06:04 -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; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388095AbhAONEm (ORCPT + 99 others); Fri, 15 Jan 2021 08:04:42 -0500 Received: from mail-ot1-f54.google.com ([209.85.210.54]:34057 "EHLO mail-ot1-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733133AbhAONEj (ORCPT ); Fri, 15 Jan 2021 08:04:39 -0500 Received: by mail-ot1-f54.google.com with SMTP id a109so8460396otc.1; Fri, 15 Jan 2021 05:04:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BfjWETeidop360v2z5Os9N6k2FYG3GkdQgvxI2qXOp8=; b=o9t1brVVRaYLL1W5ScnK1HeleKDKYneZFpzFFHOiwapTJ2h9W3wa1s31kpzwBCxK5k GMziTz0uT246G77owlTesQjwGQ7FXwByv9+WCC/GH28cW/yNgsP2DnRK/8ZVO8NVxEWv PoKQrUGu8E62/Qc35alYbB+t/hucl5TarIiEF0P6xNa9qXdlRngO5fo1pLoEuU5/d//4 DtBWcp++8Cj+LelwRyCp2MrzTSBdw/rT/ygq0IprAQtkfZMK2CxS0etjXZJztojy3DTq 3zX/pXtsCATela/0CRVvJlulQ32cz+AH/25k+Y6Esgbt73LcmY63rTJcx1qlxQJY1fpk WSew== X-Gm-Message-State: AOAM531ar1FC2czAVPAdSlR6DjkTrb1Ap8UxmsJoYsGXEJaSU5f1bEL3 1RhYMQTRL4AhnrGBgDO1MnRyzjZ3yjUO6oYm8r4= X-Received: by 2002:a05:6830:4b5:: with SMTP id l21mr8351768otd.321.1610715838378; Fri, 15 Jan 2021 05:03:58 -0800 (PST) MIME-Version: 1.0 References: <2073294.4OfjquceTg@kreacher> In-Reply-To: From: "Rafael J. Wysocki" Date: Fri, 15 Jan 2021 14:03:47 +0100 Message-ID: Subject: Re: [PATCH] driver core: Extend device_is_dependent() To: Stephan Gerhold Cc: Saravana Kannan , "Rafael J. Wysocki" , Greg Kroah-Hartman , LKML , Linux PM Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 15, 2021 at 11:03 AM Stephan Gerhold wrote: > > 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 Thanks! > > 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. Exactly. The supplier has been initialized, which is why device_is_dependent() is invoked at all, but it has not been fully registered yet, so device_for_each_child() cannot be relied on to catch all of the possible dependencies. And I say "possible", because the dependency in question is only partially recorded in the data structures, but IMV device_link_add() should refuse to create the device link in this case too.