linux-kernel - Re: [PATCH 2/8] driver-core: add asynchronous probing support for drivers

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]

Date:	Wed, 8 Jul 2015 17:52:54 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Dan Williams <dan.j.williams@...el.com>
Cc:	"Luis R. Rodriguez" <mcgrof@...e.com>, Tom Gundersen <teg@...m.no>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Tejun Heo <tj@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Subject: Re: [PATCH 2/8] driver-core: add asynchronous probing support for
 drivers

On Wed, Jul 08, 2015 at 05:43:23PM -0700, Dan Williams wrote:
> On Mon, Jul 6, 2015 at 4:38 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> > On Sat, Jul 04, 2015 at 07:09:19AM -0700, Dan Williams wrote:
> >> The problem I ran into was needing to remove devices that still had
> >> yet to be probed and not being able to use registration completion vs
> >> the device_lock() to effectively synchronize the sub-system.
> >
> > Why do you need to "synchronize the sub-system"? The asynchronous
> > probing should be transparent to the driver. Just unregister the device
> > (or the driver) and driver core will ensure that probe() is not in
> > flight.
> 
> Async registration is indeed transparent to the driver.  The primary
> need to "flush registration" is the case of "region" devices that
> reference a set of NVDIMM devices.  A region device requires all
> related NVDIMMs to be active before the region can be enabled.

Sounds like you need to call into the subsystem to let it know that the
device is active and activate region devices when they are ready. Could
be either explicit call or you can try using bus notifiers for
bind/unbind events.

BTW, do you handle bind/unbind via sysfs (everyone forgets about this
mechanism)?

Thanks.

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/