Messages in this thread Patch in this message | ![/](/images/icornerl.gif) | | Date | Thu, 29 Jul 1999 23:27:12 +0200 | From | Kurt Garloff <> | Subject | [PATCH] depmod: Prefer kernel symbols |
| |
Hi,
I found a problem with the depmod from modutils-2.2.2-pre6.
Imagine you have modules from several kernel compilations or a set of modules and several kernels with different options. (And, before I hear you screaming that I should not do that and everything will be risky then, anyway, let me tell you that this is unavoidable for sb. making distributions. But it had probably also happended to you before, as you don't do rm -rf before make modules_install, do you? And yes, root can always shoot into his own foot, but we don't need to help him, do we?)
In this situation you call depmod to generate dependencies. Now, a module needs some symbol, which is provided both in the running kernel (which has the same version as modules) and in some other module. Should the other module then be put as a dependency?
My answer is no. If all needed symbols are in the kernel, we should _not_ consider loading a module providing this symbol. Sadly, depmod's answer is sometimes yes.
Consequently, modprobe will try to unnecessarily load modules. If you are lucky, insmod will fail and the final module is just not loaded. Bad enough, because it could easily loaded, if you would not try the other one before ... But there are even worse cases: sg depends on scsi_mod in spite of scsi support being in the kernel. Loading of scsi_mod will succeed (!), but you loose access to your disks (!!) (You can try this, but please sync before, so e2fsck has not too hard a work to recover your fs. Don't blame me for your lost data!)
While you can work around by deleting all offending modules, I would prefer depmod not to produce spurious dependencies. The solution is easily achieved: If a symbol is found in kernel, prefer this one and don't generate a dependency to another module providing it.
Probably a clean solution would be to change depmod to create two symbol tables and first try the prefered, the kernel one and only look into the module symbol table, if this fails. However, I added a quick and dirty patch to depmod to prefer kernel modules: In the routine to resolve symbols I changed it to go on looking for more places until no more places are found or until a symbol in the kernel is found. If the latter is true, this one is stored as dependency, otherwise the first one found. A patch for this is appended.
I'd suggest to apply this patch to depmod until sb. comes up with a better solution. Let me add that it solved a couple if problems with some major distro ;-)
Comments are welcome, -- Kurt Garloff <garloff@suse.de> SuSE GmbH, Nürnberg, FRG Linux kernel development; SCSI drivers: tmscsim(DC390), DC395 --- depmod/depmod.c.orig Thu Mar 25 13:16:37 1999 +++ depmod/depmod.c Thu Jul 22 14:58:11 1999 @@ -171,12 +171,17 @@ for (find = symhash[psym->hashval]; find; find = find->next) { if (strcmp(find->name, psym->name) == 0) { - psym->status = SYM_RESOLVED; - psym->module = find->module; - break; + /* garloff@suse.de, 99/07/22: */ + /* Prefer kernel symbols! */ + if (psym->status == SYM_UNDEF || !strcmp(find->module->name,"-")) { + psym->status = SYM_RESOLVED; + psym->module = find->module; + /* break; */ + if (!strcmp(find->module->name,"-")) break; + } } } - if (!find) + if (psym->status == SYM_UNDEF) resolved = 0; /* still unresolved */ } }[unhandled content-type:application/pgp-signature] | ![\](/images/icornerr.gif) |