linux-kernel - Re: [driver-core PATCH v9 1/9] driver core: Establish order of operations for device_add and device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190118155042.GA5009@kroah.com>
Date:   Fri, 18 Jan 2019 16:50:42 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Alexander Duyck <alexander.h.duyck@...ux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Luis R. Rodriguez" <mcgrof@...nel.org>,
        "linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>,
        Tejun Heo <tj@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>,
        zwisler@...nel.org, Dan Williams <dan.j.williams@...el.com>,
        dave.jiang@...el.com, bvanassche@....org
Subject: Re: [driver-core PATCH v9 1/9] driver core: Establish order of
 operations for device_add and device_del via bitflag

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@...ux.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@...el.com>
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@...ux.intel.com>
> > > 
> > > Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@...el.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