Re: modprobe + request_module() deadlock

[Rusty Russell]

On Thu, 2004-11-25 at 17:03 +0100, Gerd Knorr wrote:
> On Wed, Nov 24, 2004 at 04:02:31PM +1100, Rusty Russell wrote:
> > On Mon, 2004-11-22 at 17:52 +0100, Gerd Knorr wrote:
> > > > > I can fix that in the driver, by delaying the request_module() somehow
> > > > > until the saa7134 module initialization is finished.  I don't think that
> > > > > this is a good idea through as it looks like I'm not the only one with
> > > > > that problem ...
> > > > 
> > > > Delaying request_module() sounds ugly. Anyway, if you can
> > > > get it to work reliably...
> > > 
> > > I think I can, havn't tried yet through.
> 
> Untested proof-of-concept code (don't have a saa7134 card in my machine
> at the moment), but that way it could work I think.  Tried to keep it
> generic.  Basically it keeps a list of pending module loads and the
> dependencies.  Then it hooks into the module state notifier chain and
> calls request_module() once the depending module went to LIVE state.
> 
> Comments?

A little generic for my tastes.  I was thinking more like the below
(equally untested).  Note that strictly we should call the module
notifier for NULL at the end of the boot sequence, too.
===
static int want_empress, want_dvb;

/* These need our symbols: we must be fully loaded for them to load */
static int pending_call(struct notifier_block *self, unsigned long state,
			void *module)
{
	if (module != THIS_MODULE || state != MODULE_STATE_LIVE)
		return NOTIFY_DONE;

	if (want_empress)
		request_module("saa7134-empress");
	if (want_dvb)
		request_module("saa7134-dvb);
	return NOTIFY_DONE;
}

static struct notifier_block pending_notifier = {
	.notifier_call = pending_call,
};

int init(void)
{
,,,
	register_module_notifier(&pending_notifier);
}

void cleanup(void)
{
...
	unregister_module_notifier(&pending_notifier);
}


-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

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