Re: [PATCH] platform_driver_register: warn if probe is in.init.text

From: Greg KH
Date: Wed Jan 27 2010 - 20:24:00 EST


On Tue, Jan 26, 2010 at 09:47:41AM +0100, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Jan 25, 2010 at 06:09:01AM +0900, OGAWA Hirofumi wrote:
> > Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> writes:
> >
> > > +int platform_driver_register(struct platform_driver *drv)
> > > +{
> > > + int ret = __platform_driver_register(drv);
> > > +
> > > +#if defined(CONFIG_HOTPLUG)
> > > + /*
> > > + * drivers that are registered by platform_driver_register
> > > + * should not have their probe function in .init.text. The
> > > + * reason is that a probe can happen after .init.text is
> > > + * discarded which then results in an oops. The alternatives
> > > + * are using .devinit.text for the probe function or "register"
> > > + * with platform_driver_probe.
> > > + */
> > > + if (drv->probe && kernel_init_text_address((unsigned long)drv->probe))
> > > + pr_warning("oops-warning: probe function of platform driver %s"
> > > + " lives in .init.text\n", drv->driver.name);
> > > +#else
> > > + /*
> > > + * without HOTPLUG probe functions can be discarded after the driver is
> > > + * loaded.
> > > + * There is a little chance for false positives, namely if the driver is
> > > + * registered after the .init sections are discarded.
> > > + */
> > > + if (drv->probe && !kernel_init_text_address((unsigned long)drv->probe))
> > > + pr_info("probably the probe function of platform driver %s can"
> > > + " be moved to .init.text\n", drv->driver.name);
> > > +#endif
> > > + return ret;
> > > +}
> >
> > Um..., can't we extend modpost or such one for this? I think the static
> > analysis is better (assume the changing ->probe dynamically is really
> > rare).
> I like the idea and will look later into modpost if this can be done
> there.

That would be nice to do instead, as we already do checks like this
today, and might make more sense.

And could you do it for all probe functions, and not just the platform
devices? Don't all busses have this same problem?

thanks,

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