linux-kernel - Re: [RESEND PATCH] driver core: Clear FWNODE_FLAG_LINKS_ADDED in device_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] [day] [month] [year] [list]

Date:   Thu, 5 Oct 2023 16:19:44 +0530
From:   Pavan Kondeti <quic_pkondeti@...cinc.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     Zhenhua Huang <quic_zhenhuah@...cinc.com>, <rafael@...nel.org>,
        <linux-kernel@...r.kernel.org>, <quic_pkondeti@...cinc.com>,
        <quic_tingweiz@...cinc.com>, <saravanak@...gle.com>
Subject: Re: [RESEND PATCH] driver core: Clear FWNODE_FLAG_LINKS_ADDED in
 device_links_purge()

On Thu, Oct 05, 2023 at 11:32:22AM +0200, Greg KH wrote:
> On Wed, Sep 27, 2023 at 10:30:10AM +0800, Zhenhua Huang wrote:
> > Flag FWNODE_FLAG_LINKS_ADDED stops fwnode links creation. Current kernel
> > only adds it once after fwnode links creation in fw_devlink_parse_fwnode().
> > After that even device links being purged, the flag will not be cleared.
> > 
> > Fwnode links are converted to device links and will not be added back
> > forever in normal case. Essentially if a device is registered and
> > unregisted (also deleted) before it is probed (due to missing fwlink
> > dependencies, abort in device_links_check_suppliers), the fwlink is not
> > setup next when device is newly created again. This means the probe gets
> > called without meeting all dependencies.
> > 
> > It usuallly happens in the case of a glue driver.
> 
> What exact glue driver is causing this to happen?  Why can't we fix that
> up instead?
> 

Yes, we are looking at fixing the glue driver and/or the probe order of drivers
involed by controlling modules load order. To answer your question,

It is observed with dwc3-qcom on a downstream kernel based on
Android GKI 6.1 kernel.

usb_1: usb@...8800 {
	...
	usb_1_dwc3: usb@...0000 {
		compatible = "snps,dwc3";
		iommus = <&apps_smmu 0x40 0x0>;
		...
	};
};

The parent device has no dependency on IOMMU but the child has
dependency. The parent probe gets called before IOMMU is probed.
The parent glue driver adds the child device and removes it since its
probe is not completed. Once the child is unregistered, all the fwlinks
are lost. Next time when the child is added, its probe gets called
before IOMMU is ready (since the fwlinks are lost). 

Thanks,
Pavan