All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Len Brown <len.brown@intel.com>,
	bvanassche@acm.org,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	Pavel Machek <pavel@ucw.cz>,
	zwisler@kernel.org, Tejun Heo <tj@kernel.org>,
	alexander.h.duyck@linux.intel.com,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag
Date: Thu, 20 Dec 2018 16:28:44 +0100	[thread overview]
Message-ID: <20181220152844.GA27498@kroah.com> (raw)
In-Reply-To: <CAJZ5v0hSWOb4b7FWJmfi86mYY+T1kedtC=ydS8VMUvpH4ctzbw@mail.gmail.com>

On Wed, Dec 19, 2018 at 03:27:48PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 13, 2018 at 1:45 AM Alexander Duyck
> <alexander.h.duyck@linux.intel.com> 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.
> >
> > One additional change added was that I pulled the check for dev->driver
> > out of the __device_attach_driver call and instead placed it in the
> > __device_attach_async_helper call. This was motivated by the fact that the
> > only other caller of this, __device_attach, had already taken the
> > device_lock() and checked for dev->driver. Instead of testing for this
> > twice in this path it makes more sense to just consolidate the dev->dead
> > and dev->driver checks together into one set of checks.
> >
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

It's too late for 4.21-rc1 as my tree should be closed by now.

So I'll hold on to these in my queue until 4.21-rc1 is out and then
queue them up and see what breaks in linux-next :)

thanks,

greg k-h
_______________________________________________
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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: alexander.h.duyck@linux.intel.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Luis R. Rodriguez" <mcgrof@kernel.org>,
	"linux-nvdimm@lists.01.org" <linux-nvdimm@lists.01.org>,
	Tejun Heo <tj@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux PM <linux-pm@vger.kernel.org>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	zwisler@kernel.org, Dan Williams <dan.j.williams@intel.com>,
	dave.jiang@intel.com, bvanassche@acm.org
Subject: Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag
Date: Thu, 20 Dec 2018 16:28:44 +0100	[thread overview]
Message-ID: <20181220152844.GA27498@kroah.com> (raw)
In-Reply-To: <CAJZ5v0hSWOb4b7FWJmfi86mYY+T1kedtC=ydS8VMUvpH4ctzbw@mail.gmail.com>

On Wed, Dec 19, 2018 at 03:27:48PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 13, 2018 at 1:45 AM Alexander Duyck
> <alexander.h.duyck@linux.intel.com> 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.
> >
> > One additional change added was that I pulled the check for dev->driver
> > out of the __device_attach_driver call and instead placed it in the
> > __device_attach_async_helper call. This was motivated by the fact that the
> > only other caller of this, __device_attach, had already taken the
> > device_lock() and checked for dev->driver. Instead of testing for this
> > twice in this path it makes more sense to just consolidate the dev->dead
> > and dev->driver checks together into one set of checks.
> >
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

It's too late for 4.21-rc1 as my tree should be closed by now.

So I'll hold on to these in my queue until 4.21-rc1 is out and then
queue them up and see what breaks in linux-next :)

thanks,

greg k-h

  reply	other threads:[~2018-12-20 15:28 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13  0:44 [driver-core PATCH v9 0/9] Add NUMA aware async_schedule calls Alexander Duyck
2018-12-13  0:44 ` Alexander Duyck
2018-12-13  0:44 ` Alexander Duyck
2018-12-13  0:44 ` [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag Alexander Duyck
2018-12-13  0:44   ` Alexander Duyck
2018-12-13  0:44   ` Alexander Duyck
2018-12-19 14:27   ` Rafael J. Wysocki
2018-12-19 14:27     ` Rafael J. Wysocki
2018-12-20 15:28     ` Greg Kroah-Hartman [this message]
2018-12-20 15:28       ` Greg Kroah-Hartman
2019-01-10 17:37       ` Alexander Duyck
2019-01-10 17:37         ` Alexander Duyck
2019-01-10 17:37         ` Alexander Duyck
2019-01-18 15:50         ` Greg Kroah-Hartman
2019-01-18 15:50           ` Greg Kroah-Hartman
2019-01-18 15:50           ` Greg Kroah-Hartman
2019-01-18 15:54   ` Greg KH
2019-01-18 15:54     ` Greg KH
2019-01-18 15:54     ` Greg KH
2019-01-18 19:00     ` Alexander Duyck
2019-01-18 19:00       ` Alexander Duyck
2019-01-18 19:00       ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 2/9] device core: Consolidate locking and unlocking of parent and device Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-14 10:40   ` Rafael J. Wysocki
2018-12-14 10:40     ` Rafael J. Wysocki
2018-12-14 10:40     ` Rafael J. Wysocki
2018-12-17 16:31     ` Alexander Duyck
2018-12-17 16:31       ` Alexander Duyck
2018-12-17 16:31       ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 3/9] driver core: Probe devices asynchronously instead of the driver Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 4/9] workqueue: Provide queue_work_node to queue work near a given NUMA node Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 5/9] async: Add support for queueing on specific " Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 6/9] driver core: Attach devices on CPU local to device node Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 7/9] PM core: Use new async_schedule_dev command Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 8/9] libnvdimm: Schedule device registration on node local to the device Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45 ` [driver-core PATCH v9 9/9] driver core: Rewrite test_async_driver_probe to cover serialization and NUMA affinity Alexander Duyck
2018-12-13  0:45   ` Alexander Duyck
2018-12-13  0:45   ` 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=20181220152844.GA27498@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=bvanassche@acm.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=mcgrof@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.