On Sat, Feb 9, 2013 at 5:22 PM, Haojian Zhuang <haojian.zhuang@xxxxxxxxxx> wrote: > On 7 February 2013 00:38, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: >> On Wed, Feb 06, 2013 at 05:31:24PM +0100, Linus Walleij wrote: >>> On Wed, Feb 6, 2013 at 1:31 PM, Haojian Zhuang >>> <haojian.zhuang@xxxxxxxxxx> wrote: >>> >>> CC Grant on this issue... >>> >>> > On 6 February 2013 19:52, Russell King - ARM Linux >>> > rest_init() >>> > --> creates kernel_init thread that could free __init section memory >>> > >>> > deferred_probe_initicall() creates a workqueue that is used to retry >>> > deferred probe >>> > function. >>> > >>> > I think that these two threads are competing. >>> >>> Now that is the *real* problem. The __init sections surely should >>> not be discarded until *after* all deferred probes are complete >>> and the deferral workqueue terminates. >>> >>> How about writing a patch to fix that instead? (If possible...) That just masks the issue. See below. >> >> Well, we have the facilities to flush workqueues, so it should be possible. >> >> However, I'm just wondering if this shows that we _do_ need to get rid >> of a pile of __init marked functions as well as fixing this, thanks to >> the deferred probing we now have (maybe the whole __init thing becomes >> useless with deferred probing?) There's nothing really to guarantee >> that the pinctrl stuff will be available by the time the init sections >> are discarded (it could be in a loadable module?) or indeed any other >> resources that might be necessary. If it is a probe function, then yes the __init annotations need to be removed or the driver needs to use platform_driver_probe(). This has been the model as long as I can remember. As long as a driver has a .probe hook, the driver core can call it at any time. Deferred probe has only exposed the issue. If you want to discard the .probe() hook, then the probe() pointer needs to be cleared from the driver structure before discarding the sections. Otherwise the driver core can still call it which is what happens in deferred probe and can happen if a device gets unbound from a driver and then re-attached. >> I think in this regard, deferred probing has opened a similar can of >> worms which hotplug devices created (which eventually ended up with >> killing the __dev* marking). > > At first, I considered to remove those __init functions. But it may seem > unreasonable. > > Now I'm trying to reuse wait_for_device_probe() after do_initcalls(). Please > help to review. That patch doesn't actually fix the problem, it just masks it. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
