linux-kernel - Re: [PATCH v1] driver core: Fix handling of fw

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]

Message-ID: <781eefdc-c926-7566-5305-bb9633e6fac0@samsung.com>
Date:   Tue, 31 Mar 2020 07:43:28 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Saravana Kannan <saravanak@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     kernel-team@...roid.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] driver core: Fix handling of fw_devlink=permissive

Hi,

On 2020-03-31 04:28, Saravana Kannan wrote:
> When commit 8375e74f2bca ("driver core: Add fw_devlink kernel
> commandline option") added fw_devlink, it didn't implement "permissive"
> mode correctly.
>
> That commit got the device links flags correct to make sure unprobed
> suppliers don't block the probing of a consumer. However, if a consumer
> is waiting for mandatory suppliers to register, that could still block a
> consumer from probing.
>
> This commit fixes that by making sure in permissive mode, all suppliers
> to a consumer are treated as a optional suppliers. So, even if a
> consumer is waiting for suppliers to register and link itself (using the
> DL_FLAG_SYNC_STATE_ONLY flag) to the supplier, the consumer is never
> blocked from probing.
>
> Fixes: 8375e74f2bca ("driver core: Add fw_devlink kernel commandline option")
> Reported-by: Marek Szyprowski <m.szyprowski@...sung.com>
> Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> ---
> Hi Marek,
>
> If you pull in this patch and then add back in my patch that created the
> boot problem for you, can you see if that fixes the boot issue for you?

Indeed, this fixes booting on my Raspberry Pi3/4 boards with linux 
next-20200327. Thanks! :)

Tested-by: Marek Szyprowski <m.szyprowski@...sung.com>

>
> Thanks,
> Saravana
>
>   drivers/base/core.c | 7 ++++++-
>   1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 5e3cc1651c78..1be26a7f0866 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2370,6 +2370,11 @@ u32 fw_devlink_get_flags(void)
>   	return fw_devlink_flags;
>   }
>   
> +static bool fw_devlink_is_permissive(void)
> +{
> +	return fw_devlink_flags == DL_FLAG_SYNC_STATE_ONLY;
> +}
> +
>   /**
>    * device_add - add device to device hierarchy.
>    * @dev: device.
> @@ -2524,7 +2529,7 @@ int device_add(struct device *dev)
>   	if (fw_devlink_flags && is_fwnode_dev &&
>   	    fwnode_has_op(dev->fwnode, add_links)) {
>   		fw_ret = fwnode_call_int_op(dev->fwnode, add_links, dev);
> -		if (fw_ret == -ENODEV)
> +		if (fw_ret == -ENODEV && !fw_devlink_is_permissive())
>   			device_link_wait_for_mandatory_supplier(dev);
>   		else if (fw_ret)
>   			device_link_wait_for_optional_supplier(dev);

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland