linux-kernel - Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe

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:   Wed, 18 Aug 2021 12:57:36 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        alsa-devel@...a-project.org, tiwai@...e.de, vkoul@...nel.org,
        liam.r.girdwood@...ux.intel.com,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Dan Williams <dan.j.williams@...el.com>,
        Jason Gunthorpe <jgg@...dia.com>,
        Christoph Hellwig <hch@....de>,
        "Rafael J . Wysocki" <rafael@...nel.org>,
        linux-kernel@...r.kernel.org,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [RFC PATCH 1/2] driver core: export
 driver_deferred_probe_trigger()

On Wed, Aug 18, 2021 at 07:44:39AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Aug 17, 2021 at 02:00:56PM -0500, Pierre-Louis Bossart wrote:

> > In these cases, there is no way to notify the deferred probe
> > infrastructure of the enablement of resources after the driver
> > binding.

> Then just wait for it to happen naturally?

Through what mechanism will it happen naturally?  Deferred probe
currently only does things if things are being registered or if probes
complete.

> > The driver_deferred_probe_trigger() function is currently used
> > 'anytime a driver is successfully bound to a device', this patch
> > suggest exporing by exporting it so that drivers can kick-off
> > re-probing of deferred devices at the end of a deferred processing.

> I really do not want to export this as it will get really messy very
> quickly with different drivers/busses attempting to call this.

I'm not sure I see the mess here - it's just queueing some work, one of
the things that the workqueue stuff does well is handle things getting
scheduled while they're already queued.  Honestly having understood
their problem I think we need to be adding these calls into all the
resource provider APIs.

> Either handle it in your driver (why do you have to defer probe at all,
> just succeed and move on to register the needed stuff after you are
> initialized) or rely on the driver core here.

That's exactly what they're doing currently and the driver core isn't
delivering.

Driver A is slow to start up and providing a resource to driver B, this
gets handled in driver A by succeeding immediately and then registering
the resource once the startup has completed.  Unfortunately while that
was happening not only has driver B registered and deferred but the rest
of the probes/defers in the system have completed so the deferred probe
mechanism is idle.  Nothing currently tells the deferred probe mechanism
that a new resource is now available so it never retries the probe of
driver B.  The only way I can see to fix this without modifying the
driver core is to make driver A block during probe but that would at
best slow down boot.

The issue is that the driver core is using drivers completing probe as a
proxy for resources becoming available.  That works most of the time
because most probes are fully synchronous but it breaks down if a
resource provider registers resources outside of probe, we might still
be fine if system boot is still happening and something else probes but
only through luck.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)