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@gmail.com, brendanhiggins@google.com
Subject: Re: [driver-core PATCH v7 2/9] driver core: Establish clear order of operations for deferred probe and remove
Date: Fri, 30 Nov 2018 15:40:38 -0800 [thread overview]
Message-ID: <20181130234038.GF28501@garbanzo.do-not-panic.com> (raw)
In-Reply-To: <154345153672.18040.3771035148218843351.stgit@ahduyck-desk1.amr.corp.intel.com>
On Wed, Nov 28, 2018 at 04:32:16PM -0800, Alexander Duyck wrote:
> Add an additional bit flag to the device struct named async_probe. This
> additional flag allows us to guarantee ordering between probe and remove
> operations.
>
> This allows us to guarantee that if we execute a remove operation on a
> given interface it will not attempt to update the driver member
> asynchronously following the earlier operation. Previously this guarantee
> was not present and could result in us attempting to remove a driver from
> an interface only to have it attempt to attach the driver later when we
> finally complete the deferred asynchronous probe call.
>
> Reviewed-by: Bart Van Assche <bvanassche@acm.org>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
This is the sort of corner case that is best if we had a test case for
it, as it is hard to reproduce and -- how do we know we won't regress
later? Not sure if it helps but we have lib/test_kmod.c and its
respective tools/testing/selftests/kmod/kmod.sh, a new enum kmod_test_case
might be in order for device emulation creeping up / disappearing
during a custom mock driver using async probe.
Yeah.. I know.. "yes this seems good but how about later"? While we're going
through the motions here and have your attention on this I think it
would be valuable for this now. This is the sort of code that won't
change often, but if modified *can* really break things badly.
Luis
> ---
> drivers/base/dd.c | 16 ++++++++++++++++
> include/linux/device.h | 3 +++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index 88713f182086..ef3f70a7cb5a 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -774,6 +774,10 @@ static void __device_attach_async_helper(void *_dev, async_cookie_t cookie)
>
> device_lock(dev);
>
> + /* nothing to do if async_probe has been cleared */
> + if (!dev->async_probe)
> + goto out_unlock;
> +
> if (dev->parent)
> pm_runtime_get_sync(dev->parent);
>
> @@ -785,6 +789,9 @@ static void __device_attach_async_helper(void *_dev, async_cookie_t cookie)
> if (dev->parent)
> pm_runtime_put(dev->parent);
>
> + /* We made our attempt at an async_probe, clear the flag */
> + dev->async_probe = false;
> +out_unlock:
> device_unlock(dev);
>
> put_device(dev);
> @@ -829,6 +836,7 @@ static int __device_attach(struct device *dev, bool allow_async)
> */
> dev_dbg(dev, "scheduling asynchronous probe\n");
> get_device(dev);
> + dev->async_probe = true;
> async_schedule(__device_attach_async_helper, dev);
> } else {
> pm_request_idle(dev);
> @@ -929,6 +937,14 @@ static void __device_release_driver(struct device *dev, struct device *parent)
> {
> struct device_driver *drv;
>
> + /*
> + * In the event that we are asked to release the driver on an
> + * interface that is still waiting on a probe we can just terminate
> + * the probe by setting async_probe to false. When the async call
> + * is finally completed it will see this state and just exit.
> + */
> + dev->async_probe = false;
> +
> drv = dev->driver;
> if (drv) {
> while (device_links_busy(dev)) {
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 1b25c7a43f4c..4d2eb2c74149 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -957,6 +957,8 @@ struct dev_links_info {
> * device.
> * @dma_coherent: this particular device is dma coherent, even if the
> * architecture supports non-coherent devices.
> + * @async_probe: This device has an asynchronous probe event pending. Should
> + * only be updated while holding device lock.
> *
> * At the lowest level, every device in a Linux system is represented by an
> * instance of struct device. The device structure contains the information
> @@ -1051,6 +1053,7 @@ struct device {
> defined(CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU_ALL)
> bool dma_coherent:1;
> #endif
> + bool async_probe:1;
> };
>
> static inline struct device *kobj_to_dev(struct kobject *kobj)
>
next prev parent reply other threads:[~2018-11-30 23:40 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 [this message]
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
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=20181130234038.GF28501@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=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--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.