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: <a34d104a-f8e2-7977-34a5-effb7efcf288@samsung.com>
Date:   Tue, 31 Mar 2020 09:07:31 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] driver core: Fix handling of fw_devlink=permissive

Hi,

On 2020-03-31 08:18, Saravana Kannan wrote:
> On Mon, Mar 30, 2020 at 10:43 PM Marek Szyprowski
> <m.szyprowski@...sung.com> wrote:
>> 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! :)
> Hi Marek,
>
> Thanks for testing, but I'm not able to find the tag next-20200327.

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?h=next-20200327

> I
> can only find next-20200326 and next-20200330. I was just trying to
> make sure that next-20200327 doesn't have the revert Greg did. I'm
> guessing you meant next-20200326?

I did my test on next-20200327.

$ git log --oneline next-20200327 -- drivers/base/core.c
d3ef0815f924 Merge remote-tracking branch 'driver-core/driver-core-next'
c442a0d18744 driver core: Set fw_devlink to "permissive" behavior by default
4dbe191c046e driver core: Add device links from fwnode only for the 
primary device
1d3435793123 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
9a2dd570591e Merge 5.6-rc5 into driver-core-next
9211f0a6a91a driver core: fw_devlink_flags can be static
68464d79015a driver core: Add missing annotation for 
device_links_write_lock()
ab7789c5174c driver core: Add missing annotation for 
device_links_read_lock()
8375e74f2bca driver core: Add fw_devlink kernel commandline option
^C

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