Linux Power Management development
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.h.duyck-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
To: Dan Williams <dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "Brown, Len" <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	bvanassche-HInyCGIudOg@public.gmane.org,
	linux-nvdimm
	<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
	Greg KH
	<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Linux-pm mailing list
	<linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"Luis R. Rodriguez"
	<mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Pavel Machek <pavel-+ZI9xUNit7I@public.gmane.org>,
	zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
	Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	"Rafael J. Wysocki"
	<rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Subject: Re: [driver-core PATCH v8 2/9] driver core: Establish order of operations for device_add and device_del via bitflag
Date: Mon, 10 Dec 2018 11:35:02 -0800	[thread overview]
Message-ID: <15b6817fd945a1622afe673b46b028bacefad72b.camel@linux.intel.com> (raw)
In-Reply-To: <CAPcyv4jH_Op-xHTd2FwQizPaWFx_2FE-pVsOLLmZAEK8EVPrYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Mon, 2018-12-10 at 10:58 -0800, Dan Williams wrote:
> On Wed, Dec 5, 2018 at 9:25 AM Alexander Duyck
> <alexander.h.duyck-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> wrote:
> > 
> > Add an additional bit flag to the device struct named "dead".
> > 
> > This additional flag provides a guarantee that when a device_del is
> > executed on a given interface an async worker will not attempt to attach
> > the driver following the earlier device_del call. Previously this
> > guarantee was not present and could result in the device_del call
> > attempting to remove a driver from an interface only to have the async
> > worker attempt to probe the driver later when it finally completes the
> > asynchronous probe call.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > ---
> >  drivers/base/core.c    |   11 +++++++++++
> >  drivers/base/dd.c      |    8 ++++++--
> >  include/linux/device.h |    5 +++++
> >  3 files changed, 22 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > index f3e6ca4170b4..70358327303b 100644
> > --- a/drivers/base/core.c
> > +++ b/drivers/base/core.c
> > @@ -2075,6 +2075,17 @@ void device_del(struct device *dev)
> >         struct kobject *glue_dir = NULL;
> >         struct class_interface *class_intf;
> > 
> > +       /*
> > +        * Hold the device lock and set the "dead" flag to guarantee that
> > +        * the update behavior is consistent with the other bitfields near
> > +        * it and that we cannot have an asynchronous probe routine trying
> > +        * to run while we are tearing out the bus/class/sysfs from
> > +        * underneath the device.
> > +        */
> > +       device_lock(dev);
> > +       dev->dead = true;
> > +       device_unlock(dev);
> > +
> >         /* Notify clients of device removal.  This call must come
> >          * before dpm_sysfs_remove().
> >          */
> > diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> > index 88713f182086..3bb8c3e0f3da 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);
> > 
> > +       /* device is or has been removed from the bus, just bail out */
> > +       if (dev->dead)
> > +               goto out_unlock;
> > +
> 
> What do you think about moving this check into
> __device_attach_driver() alongside all the other checks? That way we
> also get ->dead checking through the __device_attach() path.

I'm not really sure that is the best spot to do that. Part of the
reason being that by placing it where I did we avoid messing with the
runtime power management for the parent if it was already powered off.

If anything I would say we could probably look at pulling the check out
and placing the driver check in __device_attach_async_helper since from
what I can tell the check is actually redundant in the non-async path
anyway since __device_attach already had taken the device lock and
checked dev->driver prior to calling __device_attach_driver.

> ...and after that maybe it could be made a common helper
> (dev_driver_checks()?) shared between __device_attach_driver() and
> __driver_attach() to reduce some duplication.

I'm not sure consolidating it into a function would really be worth the
extra effort. It would essentially just obfuscate the checks and I am
not sure you really save much with:
	if (dev_driver_checks(dev))
vs:
	if (!dev->dead && !dev->driver)

By the time you create the function and replace the few spots that are
making these checks you would end up most likely adding more complexity
to the kernel rather than reducing it any.

  parent reply	other threads:[~2018-12-10 19:35 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 17:25 [driver-core PATCH v8 0/9] Add NUMA aware async_schedule calls Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 1/9] driver core: Move async_synchronize_full call Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 2/9] driver core: Establish order of operations for device_add and device_del via bitflag Alexander Duyck
2018-12-10 18:58   ` Dan Williams
     [not found]     ` <CAPcyv4jH_Op-xHTd2FwQizPaWFx_2FE-pVsOLLmZAEK8EVPrYg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-12-10 19:35       ` Alexander Duyck [this message]
2018-12-10 19:43         ` Dan Williams
     [not found]           ` <CAPcyv4i1RTrKYX0YpyCRE=pqt3pHBRiCGQq1wYUriLjKKTVA7A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-12-10 20:57             ` Alexander Duyck
     [not found]               ` <bd92d0a3ff60097bf4424ff4c556a5369e66da6d.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-12-10 21:15                 ` Dan Williams
2018-12-10 21:23                   ` Dan Williams
     [not found]                     ` <CAPcyv4hrML3SKnFP9UANC-hdTrpnOx4nWX=b-yhLsLuujL5oAA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-12-10 22:24                       ` Alexander Duyck
     [not found]                         ` <00810f93b199c524378b5c963d49bd798c5d9843.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-12-10 22:41                           ` Dan Williams
2018-12-05 17:25 ` [driver-core PATCH v8 3/9] device core: Consolidate locking and unlocking of parent and device Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 4/9] driver core: Probe devices asynchronously instead of the driver Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 5/9] workqueue: Provide queue_work_node to queue work near a given NUMA node Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 6/9] async: Add support for queueing on specific " Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 7/9] driver core: Attach devices on CPU local to device node Alexander Duyck
2018-12-05 17:25 ` [driver-core PATCH v8 8/9] PM core: Use new async_schedule_dev command Alexander Duyck
2018-12-05 17:26 ` [driver-core PATCH v8 9/9] libnvdimm: Schedule device registration on node local to the device Alexander Duyck
2018-12-10 19:22 ` [driver-core PATCH v8 0/9] Add NUMA aware async_schedule calls Luis Chamberlain
2018-12-10 23:25   ` Alexander Duyck
     [not found]     ` <dd0b44d5dd9d19ac6735f80ae66bb437ec55b2cf.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-12-10 23:35       ` Luis Chamberlain

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=15b6817fd945a1622afe673b46b028bacefad72b.camel@linux.intel.com \
    --to=alexander.h.duyck-vuqaysv1563yd54fqh9/ca@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=bvanassche-HInyCGIudOg@public.gmane.org \
    --cc=dan.j.williams-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
    --cc=jiangshanlai-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=mcgrof-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=pavel-+ZI9xUNit7I@public.gmane.org \
    --cc=rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=zwisler-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox