What I meant to suggest was that you should see if something
like
slot->f_state = 0;
or
slot->f_state &= ~(LIS_MODSTATE_INITED|LIS_MODSTATE_LOADED);would work, instead of or in addition to adding
slot->f_name[0] = '\0';
as you did. But it seems to me also that you should either do as you suggest, i.e., init/destroy fmodsw semaphores only once, or also add
lis_sem_destroy(&slot->f_sem) ; + slot->f_sem = NULL;
And only init (e.g., in lis_register_strmod) when the reference is NULL, i.e.,
+ if (!lis_fmod_sw[id].f_sem)
lis_sem_init(&lis_fmod_sw[id].f_sem, 1) ;I.e., making the name unusable doesn't deal directly with the dangling semaphore reference, which is likely the problem that causes the OOPS you have experienced. (I.e., f_sem is invalid after lis_sem_destroy(), and should have been NULLed to so indicate, and that indication appropriately observed.)
-John
Brian F. G. Bidulock wrote:
John,
I know there are other ways to do it, but I don't have the time for them just now.
An approach that would fix the problem but likely not change anything else would be to initialize all the semaphores in the fmodsw array on "streams" module loading and never destroy them (the memory will unload with the "streams" module). Because the fmodsw table is statically allocated, it seems pointless to destroy the semaphores in the first place.
But for now, at least for me, kernel oops on module unloading and reloading is unacceptable. For me, oss of some functionality would be preferrable.
I have uploaded an LiS-2.16.18-6 rpm at http://www.openss7.org/rpms/ that has the change if someone wants to test some of the other functionality to see if anything has been broken by the change.
--brian
On Sun, 15 Feb 2004, John A. Boyd Jr. wrote:
Let me restate in the form of a suggestion - instead of clearing the name, you might want to look at how to get the state change to work, so as to prevent this problem. The author apparently intended clearing the _INITED state flag to have somewhat the effect as your clearing of the name...
-John
Brian F. G. Bidulock wrote:
There is a module loading bug in head/mod.c When a module is unregistered the f_name component is left alloing lis_findmod to find it an lis_loadmod will attempt to lock a destroyed semaphore. The problem can be recreated by manually loading a streams kernel module (modprobe), unloading it (rmmod) and then demand loading it (e.g. I_PUSH). The result is a kernel oops.
The patch below fixes the problem (but may break other things).
--brian
Index: head/mod.c =================================================================== RCS file: /home/common/cvsroot/LiSnew/head/mod.c,v retrieving revision 1.1.1.4 diff -U3 -r1.1.1.4 mod.c --- head/mod.c 22 Nov 2003 23:01:43 -0000 1.1.1.4 +++ head/mod.c 15 Feb 2004 18:05:31 -0000 @@ -742,6 +742,7 @@ lis_up(&slot->f_sem) ; lis_sem_destroy(&slot->f_sem) ; slot->f_state &= ~LIS_MODSTATE_INITED ; + slot->f_name[0] = '\0';
printk("STREAMS module \"%s\" unregistered, id %d\n", name, id);
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
