Question about insmod/busybox

[Denys Vlasenko]

On Friday 02 November 2007 16:05, Yann E. MORIN wrote:
> Hello Khem!
> 
> Would have been great if you had CCed the busybox mailing list. :-|
> 
> So first thing you have to know: I don't know much of the insmod code. I
> maintain the modprobe code when bugs arise, but insmod (at least for 2.4)
> is too complex for me (plus I don't use 2.4 any more, and 2.6 is clean).
> 
> On Thursday 01 November 2007 20:18:17 Khem Raj wrote:
> > I have a question for you about busybox/insmod. I am modifying this so
> > that it can load more than one module in one invocation.
> > In such a scenario I get a kernel crash after a while when I try to
> > insmod 50 modules.

2.4 insmod is big and complex.

[taking a look, removing 0.5k of bloat]

Since you are getting _kernel_ crash, obviously in your case you get
corrupted data loaded into kernel. IOW: the module's images loaded by
50 successive insmods is different from images loaded by your modified
insmod.

You have two options:

add hexdumping debug to all pieces of data loaded into kernel
(you will need to instrument insmod for that), compare
results of 50 insmods with results of modified-insmod-of-50-modules,
and find out what is different.

    or

use "50 insmods" approach, since you are likely to stop using 2.4 insmod
anyway in a year or two.

> > If I write a shell script which calls insmod 50 times to insert modules
> > one by one it works.
> 
> That is exactly what I would have suggested: create a script that loops
> and calls insmod for each module.

Yes.

> > The modification I do to the insmod is a wrapper which calls
> > insmod_ng_main () in a while loop and does the argv processing.

Wait a second. Are you using _2.6_ insmod? It is very simple.

> I would say: don't do that, unless the real insmod understands more than
> one module as arguments, which I highly doubt.
> 
> We try to maintain a compatible API between "original" applications and
> the corresponding applets in busybox.
> 
> > In this scenario a kernel oops is triggered.

Well, the same idea holds, but you need to add debugging only in one place:

        len = MAXINT(ssize_t);
        map = xmalloc_open_read_close(filename, &len);
/* print len, address and hex dump of bytes read */
        ret = syscall(__NR_init_module, map, len, options);

Check whether len, alignment or contents are changed.

Sou probably also want to add some free() statements, insmod_ng_main()
is rather careless with allocated memory. This does not explain kernel oops,
though.

> > Now I want to know if insmod is written assuming that only 1 module is
> > installed in that case it will not free the malloc'ed memory and this is
> >  being caused by memory leak or if there is real problem in kernel.

Memory leaks in userspace generally cannot cause kernel oopses.
--
vda