From: Luis Chamberlain <mcgrof@kernel.org>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: len.brown@intel.com, Dmitry Torokhov <dmitry.torokhov@gmail.com>,
bvanassche@acm.org, linux-pm@vger.kernel.org,
gregkh@linuxfoundation.org, linux-nvdimm@lists.01.org,
jiangshanlai@gmail.com, linux-kernel@vger.kernel.org,
brendanhiggins@google.com, pavel@ucw.cz, zwisler@kernel.org,
tj@kernel.org, akpm@linux-foundation.org, rafael@kernel.org
Subject: Re: [driver-core PATCH v7 4/9] driver core: Probe devices asynchronously instead of the driver
Date: Fri, 30 Nov 2018 18:48:47 -0800 [thread overview]
Message-ID: <20181201024847.GH28501@garbanzo.do-not-panic.com> (raw)
In-Reply-To: <154345154692.18040.8161459765233879389.stgit@ahduyck-desk1.amr.corp.intel.com>
On Wed, Nov 28, 2018 at 04:32:26PM -0800, Alexander Duyck wrote:
> Probe devices asynchronously instead of the driver.
> +static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
> +{
> + struct device *dev = _dev;
> + struct device_driver *drv;
> +
> + __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.
> + */
> + drv = dev_get_drv_async(dev);
> + if (drv && !dev->driver)
> + driver_probe_device(drv, dev);
I believe this should mean drivers which have async work on probe can
deadlock. For instance, if a driver does call async_schedule() or a
derivative call does this for it, the kernel will call
async_synchronize_full() and I believe we deadlock.
Are we sure most subsystems which would use async probe will not have
an async_schedule() call?
Luis
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Alexander Duyck
<alexander.h.duyck-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org,
Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
bvanassche-HInyCGIudOg@public.gmane.org,
linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org,
jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
brendanhiggins-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org,
pavel-+ZI9xUNit7I@public.gmane.org,
zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
Subject: Re: [driver-core PATCH v7 4/9] driver core: Probe devices asynchronously instead of the driver
Date: Fri, 30 Nov 2018 18:48:47 -0800 [thread overview]
Message-ID: <20181201024847.GH28501@garbanzo.do-not-panic.com> (raw)
In-Reply-To: <154345154692.18040.8161459765233879389.stgit-+uVpp3jiz/SWyQ3uPIV3rPooFf0ArEBIu+b9c/7xato@public.gmane.org>
On Wed, Nov 28, 2018 at 04:32:26PM -0800, Alexander Duyck wrote:
> Probe devices asynchronously instead of the driver.
> +static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
> +{
> + struct device *dev = _dev;
> + struct device_driver *drv;
> +
> + __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.
> + */
> + drv = dev_get_drv_async(dev);
> + if (drv && !dev->driver)
> + driver_probe_device(drv, dev);
I believe this should mean drivers which have async work on probe can
deadlock. For instance, if a driver does call async_schedule() or a
derivative call does this for it, the kernel will call
async_synchronize_full() and I believe we deadlock.
Are we sure most subsystems which would use async probe will not have
an async_schedule() call?
Luis
WARNING: multiple messages have this Message-ID (diff)
From: Luis Chamberlain <mcgrof@kernel.org>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, gregkh@linuxfoundation.org,
linux-nvdimm@lists.01.org, tj@kernel.org,
akpm@linux-foundation.org, linux-pm@vger.kernel.org,
jiangshanlai@gmail.com, rafael@kernel.org, len.brown@intel.com,
pavel@ucw.cz, zwisler@kernel.org, dan.j.williams@intel.com,
dave.jiang@intel.com, bvanassche@acm.org,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
brendanhiggins@google.com
Subject: Re: [driver-core PATCH v7 4/9] driver core: Probe devices asynchronously instead of the driver
Date: Fri, 30 Nov 2018 18:48:47 -0800 [thread overview]
Message-ID: <20181201024847.GH28501@garbanzo.do-not-panic.com> (raw)
In-Reply-To: <154345154692.18040.8161459765233879389.stgit@ahduyck-desk1.amr.corp.intel.com>
On Wed, Nov 28, 2018 at 04:32:26PM -0800, Alexander Duyck wrote:
> Probe devices asynchronously instead of the driver.
> +static void __driver_attach_async_helper(void *_dev, async_cookie_t cookie)
> +{
> + struct device *dev = _dev;
> + struct device_driver *drv;
> +
> + __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.
> + */
> + drv = dev_get_drv_async(dev);
> + if (drv && !dev->driver)
> + driver_probe_device(drv, dev);
I believe this should mean drivers which have async work on probe can
deadlock. For instance, if a driver does call async_schedule() or a
derivative call does this for it, the kernel will call
async_synchronize_full() and I believe we deadlock.
Are we sure most subsystems which would use async probe will not have
an async_schedule() call?
Luis
next prev parent reply other threads:[~2018-12-01 2:48 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-29 0:32 [driver-core PATCH v7 0/9] Add NUMA aware async_schedule calls Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` [driver-core PATCH v7 1/9] driver core: Move async_synchronize_full call Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-30 23:21 ` Luis Chamberlain
2018-11-30 23:21 ` Luis Chamberlain
2018-11-30 23:21 ` Luis Chamberlain
2018-11-29 0:32 ` [driver-core PATCH v7 2/9] driver core: Establish clear order of operations for deferred probe and remove Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 1:57 ` Dan Williams
2018-11-29 18:07 ` Alexander Duyck
2018-11-29 18:07 ` Alexander Duyck
2018-11-29 18:07 ` Alexander Duyck
2018-11-29 18:55 ` Dan Williams
2018-11-29 18:55 ` Dan Williams
2018-11-29 18:55 ` Dan Williams
2018-11-29 21:53 ` Alexander Duyck
2018-11-29 21:53 ` Alexander Duyck
2018-11-29 21:53 ` Alexander Duyck
2018-11-29 22:00 ` Dan Williams
2018-11-29 22:00 ` Dan Williams
2018-11-29 22:00 ` Dan Williams
2018-11-30 23:40 ` Luis Chamberlain
2018-11-29 0:32 ` [driver-core PATCH v7 3/9] device core: Consolidate locking and unlocking of parent and device Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-12-01 0:01 ` Luis Chamberlain
2018-12-01 0:01 ` Luis Chamberlain
2018-12-01 0:01 ` Luis Chamberlain
2018-11-29 0:32 ` [driver-core PATCH v7 4/9] driver core: Probe devices asynchronously instead of the driver Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-12-01 2:48 ` Luis Chamberlain [this message]
2018-12-01 2:48 ` Luis Chamberlain
2018-12-01 2:48 ` Luis Chamberlain
2018-12-03 16:44 ` Alexander Duyck
2018-12-03 16:44 ` Alexander Duyck
2018-11-29 0:32 ` [driver-core PATCH v7 5/9] workqueue: Provide queue_work_node to queue work near a given NUMA node Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` [driver-core PATCH v7 6/9] async: Add support for queueing on specific " Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` [driver-core PATCH v7 7/9] driver core: Attach devices on CPU local to device node Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` [driver-core PATCH v7 8/9] PM core: Use new async_schedule_dev command Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` [driver-core PATCH v7 9/9] libnvdimm: Schedule device registration on node local to the device Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
2018-11-29 0:32 ` Alexander Duyck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181201024847.GH28501@garbanzo.do-not-panic.com \
--to=mcgrof@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alexander.h.duyck@linux.intel.com \
--cc=brendanhiggins@google.com \
--cc=bvanassche@acm.org \
--cc=dmitry.torokhov@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=jiangshanlai@gmail.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rafael@kernel.org \
--cc=tj@kernel.org \
--cc=zwisler@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.