linux-kernel - Re: Module init call vs symbols exporting race?

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: <200711101827.47874.rusty@rustcorp.com.au>
Date:	Sat, 10 Nov 2007 18:27:47 +1100
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Jan Glauber <jang@...ux.vnet.ibm.com>
Cc:	Jon Masters <jonathan@...masters.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Pavel Emelyanov <xemul@...nvz.org>
Subject: Re: Module init call vs symbols exporting race?

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