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: <0a72b8db91f9151ecc7f215b465ec8e69adc239c.camel@linux.intel.com>
Date:   Thu, 10 Jan 2019 09:37:32 -0800
From:   Alexander Duyck <alexander.h.duyck@...ux.intel.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     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, 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.

Thanks.

- Alex