I hadn't noticed this thread before...
Lis has long had module reference counting issues, but we've tried to keep them under control...
Since recent 2.4.2x kernels at least, there are places where the kernel itself manipulates module reference counts. There are a few important kernel structures (notably the file operations and filesystem operations structures) that keep a module reference in a field named 'owner', and various places in the filesystem-related code (which includes open(), close(), and bunches besides) use that field to take opportunity to change a module's reference count.
If you load LiS with 'modprobe streams' and check lsmod or /proc/modules, it should show 0 references. Even this is a workaround, though, achieved by leaving the 'owner' field for the root LiS superblock NULL until after it is first used (see lis_init_module).
If it's 0 at loading and you've done something with LiS after loading that leaves it non-zero, then likely either a superblock reference is bumping the count, or a LiS-based file opening/closing is bumping it, but not completely cleaning up after itself. Or, as Brian suspects, a module is trying to do its own reference counting and messing it up. That would not affect the base 'streams' module in a perfect world, but I've discovered problems in the use of the routines Brian mentions in module referencing, in just the past few days, and I've reworked that code. I think now that it might be a good idea not to do your own reference counting. Truth be told, what the kernel provided never really worked before, but 2.6 has gone a way towards cleaning it up, dealing with inter-module dependencies more effectively and automatically, and thus making the old explicit reference counting not just unnecessary, but a bad idea.
So, in the spirit of Brian's suggestion, try commenting out any module-reference-counting code you may have, and try again. It is possible that your counting calls (lis_inc_mod_cnt especially) were adding to the 'streams' count, but not to your own module(s)' count(s).
The basic problem with the old (to me, current to you) LiS calls is that they passed no module-identifying parameter, being based on MOD_[INC,DEC]_USE_COUNT, which the kernel provided. These all used THIS_MODULE, a macro which identified the module in which code was executing (and possibly NULL, if not in a module). There were "internal" kernel macros __MOD_[INC,DEC]_USE_COUNT(<module>) which maybe should have been used instead, but having used the parameter- less ones, an interesting problem might have occurred.
Namely, if a loadable module were to call, say, lis_inc_mod_cnt(), which is in the 'streams' module, the count that would be bumped would be the one corresponding to a THIS_MODULE reference at the time that code was built. That code was in linux-mdep.c, which is built into the 'streams' module. The THIS_MODULE reference thus referred to the 'streams' module, not the calling module at all.
But the kernel macros are macros. If those are referenced (and if they do something) from some other module, they would affect the count of the module to which THIS_MODULE referred, which would likely not have been the base 'streams' module in that case.
Also interesting is that instead of recognizing and resolving this potential mis-referencing, (at least some of) the related routines were defined as exported symbols, which had the effect of making them available to other loadable modules in the first place, and thus making the mis-referencing possible.
Use of the MOD_[INC,DEC]_USE_COUNT macros is deprecated and considered dangerous as of 2.6. I've already reworked all code in the LiS distribution proper to avoid any reference to them. I've replaced them with new MODGET()/MODPUT() macros which are not subject to the mis-referencing problem I just described, but I am also coming to the point where I think the use of even these new macros from typical modules is not going to be appropriate.
The old LiS convention has been to bump a module reference count at driver/module open(), and decrement it at close(), but such calls have never necessarily been 1-to-1 quantitatively. As of 2.4.2x, the kernel does module reference counting for open()/close(); even the base 'streams' module generally doesn't have to do it. As it now stands, the counting the kernel does goes against the base 'streams' module, but I would not conclude at this point that that's necessarily always going to be the case. It may be both possible and convenient to have not just one LiS file operations and file system operations structures in which to plant module references, but one per module, e.g., the new <sys/LiS/module.h> header or similar.
-John
Brian F. G. Bidulock wrote:
> Roberto,
>
> Have you contacted IBM for support? I know of no module counting problems in
> LiS proper even as far back as 2.8. There is the possibility that the driver
> is calling lis_inc_mod_cnt() inappropriately, which would increase the mod
> count on the streams.o kernel module instead of the driver kernel module.
>
> Recent LiS 'streams.o' kernel module only increases its module count when it
> allocates stdata structures in lis_alloc_stdata() and only decrements when the
> stdata (stream head) is deallocated. There are two ways for an stdata
> structure to exist: 1) attached to an open file descriptor; 2) permanently
> linked under a multiplexing driver.
>
> If you do /usr/sbin/lsof you will get a listing of open files. You cancheck
> that list to see if there are any open devices that correspond to streams
> devices that a holding the use count up at 1. If there are not, then there
> may be a stream head I_PLINK'ed under a multiplexing driver that was then
> unloaded as a kernel module. Some of the LiS debug flags to the 'streams'
> command might help there.
>
> Aside from that, it is more likely the addon driver misbehaving (calling
> lis_inc_mod_cnt() in one place and MOD_DEC_USE_COUNT in another, or notat
> all). Without access to the source for the drivers, it is not possibleto
> assist you in debugging them. If IBM has stated that they will supporttheir
> drivers on LiS 2.16.0, perhaps you could ask them to make good on that
> statement and assist you with this problem. Also, their recommendations with
> regard to LiS version may have changed since the last information that you
> have.
>
> --brian
>
> On Mon, 17 May 2004, Roberto Salomon wrote:
>
>
>> Brian,
>> We're stuck on 2.16.0 due to CS/Linux. Currently IBM only supports
>> their environment with this release of LiS... :( At least that's the
>> info they sent us.
>> Em Seg, 2004-05-17 �s 13:30, Brian F. G. Bidulock escreveu:
>>
>>Roberto,
>>
>>Ok. Why are you using LiS 2.16.0? Many things were fixed along the
>>way to 2.16.18. Try 2.16.18 and see if the problem just goes away.
>>
>>--brian
>>
>>On Mon, 17 May 2004, Roberto Salomon wrote:
>>
>>
>>> Brian,
>>> Sorry for taking so long. Our test system was busy on other tasks...
>>> :)
>>> The output of /proc/modules when LiS refuses to unload is:
>>> nls_iso8859-1 3488 1 (autoclean)
>>> nls_cp437 5120 1 (autoclean)
>>> vfat 12092 1 (autoclean)
>>> fat 36984 0 (autoclean) [vfat]
>>> usb-storage 69184 1
>>> usb-uhci 24676 0 (unused)
>>> usbcore 73792 0 [usb-storage usb-uhci]
>>> streams 568608 1
>>> eepro100 21068 1
>>> mii 3976 0 [eepro100]
>>> st 29680 0 (unused)
>>> aic7xxx 133248 5
>>> sg 33892 0 (unused)
>>> sd_mod 12828 12
>>> scsi_mod 107548 5 [usb-storage st aic7xxx sg sd_mod]
>>> ext3 65984 4
>>> jbd 47500 4 [ext3]
>>> All modules that depend on streams were unloaded.
>>>
>>>
>>>--
>>>Roberto F. Salomon
>>>Diretor de Tecnologia
>>>Techisa do Brasil Ltda. htt://[1]www.techisa.srv.br
>>>+55 61 340-6266
>>
>>
>>
>>--
>>Roberto F. Salomon
>>Diretor de Tecnologia
>>Techisa do Brasil Ltda. htt://www.techisa.srv.br
>>+55 61 340-6266
>>
>>References
>>
>> 1. http://www.techisa.srv.br/
>
>
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
