linux-kernel - RE: [PATCH 1/3] driver core: enable drivers to use deferred probe from init

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:	Mon, 28 Jul 2014 15:46:32 +0000
From:	Yuval Mintz <Yuval.Mintz@...gic.com>
To:	"Luis R. Rodriguez" <mcgrof@...e.com>
CC:	"Luis R. Rodriguez" <mcgrof@...not-panic.com>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
	Joseph Salisbury <joseph.salisbury@...onical.com>,
	Kay Sievers <kay@...y.org>,
	"One Thousand Gnomes" <gnomes@...rguk.ukuu.org.uk>,
	Tim Gardner <tim.gardner@...onical.com>,
	Pierre Fersing <pierre-fersing@...rref.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Benjamin Poirier <bpoirier@...e.de>,
	Nagalakshmi Nandigama <nagalakshmi.nandigama@...gotech.com>,
	Praveen Krishnamoorthy <praveen.krishnamoorthy@...gotech.com>,
	Sreekanth Reddy <sreekanth.reddy@...gotech.com>,
	Abhijit Mahajan <abhijit.mahajan@...gotech.com>,
	Hariprasad S <hariprasad@...lsio.com>,
	Santosh Rastapur <santosh@...lsio.com>,
	"MPT-FusionLinux.pdl@...gotech.com" 
	<MPT-FusionLinux.pdl@...gotech.com>,
	linux-scsi <linux-scsi@...r.kernel.org>,
	netdev <netdev@...r.kernel.org>
Subject: RE: [PATCH 1/3] driver core: enable drivers to use deferred probe
	from init

> Subject: Re: [PATCH 1/3] driver core: enable drivers to use deferred probe from
> init
> 
> On Mon, Jul 28, 2014 at 03:12:11PM +0000, Yuval Mintz wrote:
> > Perhaps this is a silly question, but what guarantees that the
> > deferred probe list will actually be triggered, e.g., in case the
> > delayed device is the last device in the system?
> 
> The dev->init_delayed_probe is used to ensure that we'd add the device to the
> deferred probe list once making this a per device thing if the driver has the field
> delay_probe set to true. This technically also allows this to be a per device thing
> so with some more work we could enable drivers to only enable this for specific
> devices but at this point this did not seem required.

Sorry for not being clear, but I didn't meant 'what guarantees that the device
will be added to the deferred probe', but rather what guarantees that the
deferred workqueue will be scheduled.

To the best of my knowledge the deferring mechanism works only if one device
is dependent upon another, e.g., for Multi-function devices where one device
probe is dependent upon the others - which are soon-to-be probed.

[If I'm incorrect I'd appreciate if someone could correct me]

>
> > [From drivers/base/dd.c  - "A successful driver probe will trigger
> > moving all devices from the pending to the active list so that the
> > workqueue will eventually retry them]
--
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/