Re: Module init call vs symbols exporting race?

[Rusty Russell <rusty@rustcorp.com.au>]

On Friday 09 November 2007 23:16:47 Jan Glauber wrote:
> On Fri, 2007-11-09 at 06:44 -0500, Jon Masters wrote:
> > On Thu, 2007-11-08 at 13:10 +1100, Rusty Russell wrote:
> > > On Wednesday 07 November 2007 21:01:30 Jan Glauber wrote:
> > > > Hi Rusty,
> > > >
> > > > I've seen a symbol-resolving race on s390. The qeth module uses
> > > > symbols from qdio and although the loading order seems correct and
> > > > the qdio symbols should be available the following error appears:
> > > >
> > > > qdio: loading QDIO base support version 2
> > > > qeth: Unknown symbol qdio_synchronize
> > >
> > > Looks like qdio does something which triggers qeth to load, but of
> > > course qdio isn't finished initializing yet so its symbols aren't
> > > available.
> > >
> > > It's not obvious what's triggering the load, but you could probably
> > > find it by using printk's through qdio.c's init_QDIO().
> >
> > Jan - did you get anything?
>
> I still think this is a bug in the module loader since qdio does not
> depent on qeth, qdio can be modprobe'd without automatically loading
> qeth. Adding a printk to the end of init_QDIO() inidicates that
> qeth_init() runs _after_ init_QDIO() is finished.

Of course it does: it has to.

qeth needs qdio, and qdio hasn't finished init when qeth tries to load.  
Something tries to load qeth again, and this time it works (qdio's init has 
presumably finished).

We fail rather than sleep in the "dependency isn't ready" case.  Partially 
because it's not happened before, but partially because we risk nasty loops.

Cheers,
Rusty.