From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>
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>,
"Rafael J. Wysocki" <rafael@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>,
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: Fri, 18 Jan 2019 16:50:42 +0100 [thread overview]
Message-ID: <20190118155042.GA5009@kroah.com> (raw)
In-Reply-To: <0a72b8db91f9151ecc7f215b465ec8e69adc239c.camel@linux.intel.com>
On Thu, Jan 10, 2019 at 09:37:32AM -0800, Alexander Duyck wrote:
> On Thu, 2018-12-20 at 16:28 +0100, Greg Kroah-Hartman wrote:
> > 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
>
> I just wanted to check on on this patch set in terms of workflow. Since
> it looks like we now have 5.0-rc1 out I was wondering what the ETA for
> this patch set being pulled was, or if I need to resubmit the set.
I'm reviewing it now, no need to resend...
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-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
To: Alexander Duyck
<alexander.h.duyck-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: Len Brown <len.brown-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
bvanassche-HInyCGIudOg@public.gmane.org,
"linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org"
<linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org>,
Linux PM <linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"Rafael J. Wysocki"
<rafael-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Lai Jiangshan
<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>
Subject: Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device_del via bitflag
Date: Fri, 18 Jan 2019 16:50:42 +0100 [thread overview]
Message-ID: <20190118155042.GA5009@kroah.com> (raw)
In-Reply-To: <0a72b8db91f9151ecc7f215b465ec8e69adc239c.camel-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
On Thu, Jan 10, 2019 at 09:37:32AM -0800, Alexander Duyck wrote:
> On Thu, 2018-12-20 at 16:28 +0100, Greg Kroah-Hartman wrote:
> > 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-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.
> > > >
> > > > 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-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > >
> > > Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >
> > 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
>
> I just wanted to check on on this patch set in terms of workflow. Since
> it looks like we now have 5.0-rc1 out I was wondering what the ETA for
> this patch set being pulled was, or if I need to resubmit the set.
I'm reviewing it now, no need to resend...
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
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: Fri, 18 Jan 2019 16:50:42 +0100 [thread overview]
Message-ID: <20190118155042.GA5009@kroah.com> (raw)
In-Reply-To: <0a72b8db91f9151ecc7f215b465ec8e69adc239c.camel@linux.intel.com>
On Thu, Jan 10, 2019 at 09:37:32AM -0800, Alexander Duyck wrote:
> On Thu, 2018-12-20 at 16:28 +0100, Greg Kroah-Hartman wrote:
> > 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
>
> I just wanted to check on on this patch set in terms of workflow. Since
> it looks like we now have 5.0-rc1 out I was wondering what the ETA for
> this patch set being pulled was, or if I need to resubmit the set.
I'm reviewing it now, no need to resend...
thanks,
greg k-h
next prev parent reply other threads:[~2019-01-18 15:50 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
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 [this message]
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=20190118155042.GA5009@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.