Depmod, when building its symbol dependecies, will search for any source of required symbols for a given module. This behaviour can lead to 'ghost' dependecy loops. For example: adeos.ko needs printk, rtai_hal.ko needs various symbols from adeos.ko, but provides its own printk. Depmod's current behaviour is to report the apparent loop and spit out the dependency for anything not associated with the two troublemakers. Reproducible: Always Steps to Reproduce: 1. 2. 3.
The problem can be fixed by applying the following patch to 3.0-r2: *** depmod.c~ Wed Jun 29 07:04:43 2005 --- depmod.c Wed Jun 29 07:06:10 2005 *************** *** 100,107 **** strcpy(new->name, name); hash = tdb_hash(name) % SYMBOL_HASH_SIZE; ! new->next = symbolhash[hash]; ! symbolhash[hash] = new; } static int print_unknown; --- 100,116 ---- strcpy(new->name, name); hash = tdb_hash(name) % SYMBOL_HASH_SIZE; ! /*BG: ensure the symbols from the kernel are always found first*/ ! if(!(symbolhash[hash]) || symbolhash[hash]->owner) ! { ! new->next = symbolhash[hash]; ! symbolhash[hash] = new; ! } ! else ! { ! new->next = symbolhash[hash]->next; ! symbolhash[hash]->next = new; ! } } static int print_unknown;
this applies cleanly to 3.2-pre7 it looks like
Note: real bug is that rtai_hal exports printk. That's just *stupid*. How is the kernel supposed to know which one to use? Certainly it's an interesting potential for modules mugging other modules. However, "fix" of inserting in second place in hash is not correct either: that will only work for a single symbol in each hash bucket. Right fix is probably to do search on insert of symbol, complain about broken module, and not to add the symbol. IIRC there are some modules which export the same symbols as other modules (a dubious practice, but sometimes neccessary), so you may want to suppress this unless it's a core kernel symbol being overridden. Please try this instead.
Rusty, I didn't think I'd actually have to defend this to the author of depmod... I love depmod - couldn't live without it :) So hear goes: rtai_hal exports printk because it is meant to override the kernel's printk (IIRC) so that any modules operating in its real-time domain can print kernel messages without fear of race. RTAI isn't what you would call a 'desktop' patch, but it is useful when you are building systems that need to meet real-time contraints and you don't want to shell out large for something like RTLinux. So I can't agree that it is stupid. I guess the reason this 'problem' has never popped up before is that users of RTAI are using insmod for modules, which will work with the above combination of rtai_hal and adeos. That aside, what I saw as the problem was that depmod wouldn't build the dependency list for the modules because it saw a loop that wasn't there - the kernel provided the culprit symbol all along. I apologize for using the word 'fixed' when it is clearly a workaround. It seemed to me that since insmod'ing the modules resulted in no catastrophies then depmod should be able to prepare a dep list so that modprobe could do the same. I simply exploited the fact that the symbol search was done linearly from the hash-point. If there is a rule stating that modules cannot export symbols already exported by the kernel, then rejecting those modules whose symbols override the kernel's is the go, for sure; however, you are then relegating (at least) the users of rtai to the realm of insmod forever. Which probably isn't a big deal, since it seems like they are happy there - and I'll be content forever patching depmod as the releases roll in. :) Would you accept the following? 1. implementing the search for duplicate symbols prior to the addition of the symbol to the hash-table. 2. adding a strictness level: 2-don't allow any duplication of symbols 1-allow modules to duplicate symbols from other modules (default) 0-level 1 and allow modules to duplicate symbols from the kernel.
> rtai_hal exports printk because it is meant to override the kernel's printk > (IIRC) so that any modules operating in its real-time domain can print kernel > messages without fear of race. But (1) all the internal printks are not overridden, (2) overriding symbols is undefined behavior, and (3) if you don't consider rtai_hal to be a dependency then it won't be automatically loaded by all other modules which you seem to want. The correct solution is either that rtai_hal needs to export an entry point from the real printk which allows it to override it, or to use some other name in modules which need real-time behavior. Sorry, Rusty.
Ok, I buy it. I'll move the problem to the RTAI people.
