[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1539886275.81977.17.camel@acm.org>
Date: Thu, 18 Oct 2018 11:11:15 -0700
From: Bart Van Assche <bvanassche@....org>
To: Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org
Cc: len.brown@...el.com, rafael@...nel.org, linux-pm@...r.kernel.org,
jiangshanlai@...il.com, pavel@....cz, zwisler@...nel.org,
tj@...nel.org, akpm@...ux-foundation.org
Subject: Re: [driver-core PATCH v4 4/6] driver core: Probe devices
asynchronously instead of the driver
On Mon, 2018-10-15 at 08:09 -0700, Alexander Duyck wrote:
> +static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
> +{
> + struct device *dev = _dev;
> +
> + __device_driver_lock(dev, dev->parent);
> +
> + /*
> + * If someone attempted to bind a driver either successfully or
> + * unsuccessfully before we got here we should just skip the driver
> + * probe call.
> + */
> + if (!dev->driver) {
> + struct device_driver *drv = dev_get_drvdata(dev);
> +
> + if (drv)
> + driver_probe_device(drv, dev);
> + }
> +
> + __device_driver_unlock(dev, dev->parent);
> +
> + put_device(dev);
> +
> + dev_dbg(dev, "async probe completed\n");
> +}
> +
> static int __driver_attach(struct device *dev, void *data)
> {
> struct device_driver *drv = data;
> @@ -945,6 +971,25 @@ static int __driver_attach(struct device *dev, void *data)
> return ret;
> } /* ret > 0 means positive match */
>
> + if (driver_allows_async_probing(drv)) {
> + /*
> + * Instead of probing the device synchronously we will
> + * probe it asynchronously to allow for more parallelism.
> + *
> + * We only take the device lock here in order to guarantee
> + * that the dev->driver and driver_data fields are protected
> + */
> + dev_dbg(dev, "scheduling asynchronous probe\n");
> + device_lock(dev);
> + if (!dev->driver) {
> + get_device(dev);
> + dev_set_drvdata(dev, drv);
> + async_schedule(__driver_attach_async_helper, dev);
> + }
> + device_unlock(dev);
> + return 0;
> + }
> +
> device_driver_attach(drv, dev);
What prevents that the driver pointer becomes invalid after async_schedule() has
been called and before __driver_attach_async_helper() is called? I think we need
protection against concurrent driver_unregister() and __driver_attach_async_helper()
calls. I'm not sure whether that is possible without introducing a new mutex.
Thanks,
Bart.
Powered by blists - more mailing lists