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 _______________________________________________ busybox mailing list busybox@busybox.net http://busybox.net/cgi-bin/mailman/listinfo/busybox