linux-kernel - Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

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: <20111004233504.GD3009@ponder.secretlab.ca>
Date:	Tue, 4 Oct 2011 17:35:04 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	"G, Manjunath Kondaiah" <manjugk@...com>
Cc:	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Greg Kroah-Hartman <greg@...ah.com>,
	Dilan Lee <dilee@...dia.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Manjunath GKondaiah <manjunath.gkondaiah@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, linux-omap@...r.kernel.org
Subject: Re: [RFC PATCH v3] drivercore: Add driver probe deferral mechanism

On Wed, Oct 05, 2011 at 12:05:16AM +0530, G, Manjunath Kondaiah wrote:
> On Tue, Oct 04, 2011 at 09:58:10AM -0600, Grant Likely wrote:
> > On Tue, Oct 4, 2011 at 8:51 AM, G, Manjunath Kondaiah <manjugk@...com> wrote:
> > > On Thu, Sep 22, 2011 at 12:51:23PM -0600, Grant Likely wrote:
> > >> Hi Manjunath,
> > >>
> > >> Here's the current state of the patch.  The major think that needs to
> > >> be done is to convert it to use a separate workqueue as described in
> > >> the TODO above.  It also needs some users adapted to it.  One of the
> > >> gpio drivers would work; preferably one of the newer drivers that
> > >> doesn't have a lot of drivers depending on the early_initcall()
> > >> behaviour yet.
> > >
> > > I have tested this patch on omap3 beagle board by making:
> > > 1. omap-gpio driver init as late_initcall instead of postcore_initcall
> > > 2. mmc driver probe will request gpio through gpio_request and gpio driver
> > > returns -EDEFER_PROBE which in turn makes mmc driver to request deferral probe.
> > > 3. When deferral probe gets activated, it scans driver entries and it will not
> > > find any match for mmc driver probe.
> > 
> > Looks like drivers/mmc/host/omap.c is using platform_driver_probe()
> > instead of platform_driver_register().  Add the probe hook to the
> > platform_driver structure and change it to call
> > platform_driver_register() and it should work.  Don't forget to change
> > mmc_omap_probe from __init to __devinit.
> 
> Yes. After changing it into platform_driver_register, I can see mmc probe is
> getting completed from deferred probe list. But, MMC upper layer will check 
> probe and it waits for ever since probe_count is not getting incremented.
> 
> Log:
> 
> [    1.807830] platform omap_hsmmc.0: Driver omap_hsmmc requests probe deferral
> 
> ...
> 
> [    1.948760] omap_device: omap_gpio.0: new worst case activate latency 0:30517
> [    1.959259] OMAP GPIO hardware version 2.5
> 
> ...
> 
> [    2.000488] platform omap_hsmmc.0: Retrying from deferred list
> [    2.008026] omap_device: omap_hsmmc.0: new worst case activate latency 0:244140
> [    2.020080] input: gpio-keys as /devices/platform/gpio-keys/input/input1
> [    2.035827] omap_hsmmc omap_hsmmc.0: Probe success...
> [    2.042083] twl_rtc twl_rtc: setting system clock to 2000-01-01 01:06:35 UTC
> (946688795)
> [    2.056030] Waiting for root device /dev/mmcblk0p2...
> [    2.061492] driver_probe_done: probe_count = 0
> [    2.168518] driver_probe_done: probe_count = 0
> [    2.277832] driver_probe_done: probe_count = 0
> [    2.387207] driver_probe_done: probe_count = 0
> [    2.496582] driver_probe_done: probe_count = 0
> 
> Waits for ever in init/do_mount.c:
> 	if ((ROOT_DEV == 0) && root_wait) {
> 		printk(KERN_INFO "Waiting for root device %s...\n",
> 			saved_root_name);
> 		while (driver_probe_done() != 0 ||
> 			(ROOT_DEV = name_to_dev_t(saved_root_name)) == 0)
> 			msleep(100);
> 		async_synchronize_full();
> 	}

Okay, it looks like the driver deferral workqueue needs to get kicked
off before the kernel starts waiting for the root filesystem.  Check
the initcall level that is being used by do_mount, and make sure the
deferred probe starts before that...

Hmmm.... wait, that doesn't make sense because the probe is still
successful.  What triggers the exit conditions in that while loop?
How would it be different from when the driver can probe successfully
without deferral?

g.

> 
> -Manjunath
--
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/