linux-kernel - Re: [PATCH v2 01/11] driver core: fw_devlink: Don't purge child fwnode's consumer links

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 27 Jan 2023 11:21:55 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Sudeep Holla <sudeep.holla@....com>,
        Cristian Marussi <cristian.marussi@....com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Bartosz Golaszewski <brgl@...ev.pl>,
        Thomas Gleixner <tglx@...utronix.de>,
        Marc Zyngier <maz@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Magnus Damm <magnus.damm@...il.com>,
        Len Brown <lenb@...nel.org>,
        Daniel Scally <djrscally@...il.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        Tony Lindgren <tony@...mide.com>,
        Linux Kernel Functional Testing <lkft@...aro.org>,
        Naresh Kamboju <naresh.kamboju@...aro.org>,
        Abel Vesa <abel.vesa@...aro.org>,
        Alexander Stein <alexander.stein@...tq-group.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        John Stultz <jstultz@...gle.com>,
        Doug Anderson <dianders@...omium.org>,
        Guenter Roeck <linux@...ck-us.net>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Maxim Kiselev <bigunclemax@...il.com>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Miquel Raynal <miquel.raynal@...tlin.com>,
        Luca Weiss <luca.weiss@...rphone.com>,
        Colin Foster <colin.foster@...advantage.com>,
        Martin Kepplinger <martin.kepplinger@...i.sm>,
        Jean-Philippe Brucker <jpb@...nel.org>,
        kernel-team@...roid.com, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-gpio@...r.kernel.org,
        devicetree@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
        linux-acpi@...r.kernel.org
Subject: Re: [PATCH v2 01/11] driver core: fw_devlink: Don't purge child
 fwnode's consumer links

On Thu, Jan 26, 2023 at 04:11:28PM -0800, Saravana Kannan wrote:
> When a device X is bound successfully to a driver, if it has a child
> firmware node Y that doesn't have a struct device created by then, we
> delete fwnode links where the child firmware node Y is the supplier. We
> did this to avoid blocking the consumers of the child firmware node Y
> from deferring probe indefinitely.
> 
> While that a step in the right direction, it's better to make the
> consumers of the child firmware node Y to be consumers of the device X
> because device X is probably implementing whatever functionality is
> represented by child firmware node Y. By doing this, we capture the
> device dependencies more accurately and ensure better
> probe/suspend/resume ordering.

...

>  static unsigned int defer_sync_state_count = 1;
>  static DEFINE_MUTEX(fwnode_link_lock);
>  static bool fw_devlink_is_permissive(void);
> +static void __fw_devlink_link_to_consumers(struct device *dev);
>  static bool fw_devlink_drv_reg_done;
>  static bool fw_devlink_best_effort;

I'm wondering if may avoid adding more forward declarations...

Perhaps it's a sign that devlink code should be split to its own
module?

...

> -int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup)
> +static int __fwnode_link_add(struct fwnode_handle *con,
> +			     struct fwnode_handle *sup)

I believe we tolerate a bit longer lines, so you may still have it on a single
line.

...

> +int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup)
> +{

> +	int ret = 0;

Redundant assignment.

> +	mutex_lock(&fwnode_link_lock);
> +	ret = __fwnode_link_add(con, sup);
> +	mutex_unlock(&fwnode_link_lock);
>  	return ret;
>  }

...

>  	if (dev->fwnode && dev->fwnode->dev == dev) {

You may have above something like


	fwnode = dev_fwnode(dev);
	if (fwnode && fwnode->dev == dev) {

>  		struct fwnode_handle *child;
>  		fwnode_links_purge_suppliers(dev->fwnode);
> +		mutex_lock(&fwnode_link_lock);
>  		fwnode_for_each_available_child_node(dev->fwnode, child)
> -			fw_devlink_purge_absent_suppliers(child);
> +			__fw_devlink_pickup_dangling_consumers(child,
> +							       dev->fwnode);

			__fw_devlink_pickup_dangling_consumers(child, fwnode);

> +		__fw_devlink_link_to_consumers(dev);
> +		mutex_unlock(&fwnode_link_lock);
>  	}

-- 
With Best Regards,
Andy Shevchenko