On Mon, Dec 09, 2002 at 04:36:50PM +0100, Edward Gerhold wrote: > Hmmm. That 's new for me. In my Books ldd (german) on page 36 > and lnx-networkarchitecture (german) on page 37 they write, we > have to use the MOD_INC_.. and MOD_DEC_.. macros to set MOD_IN_USE. > MOD_INC_USE_COUNT has to be used _before_ opening any devices. > MOD_DEC_USE_COUNT has to be used _after_ closing any devices. > (Wehrle writes: A dev->open() increases the usage-counter by 1, > a dev->close() decreases the counter by 1 - both automatically) > MOD_IN_USE is used to prevent from a module_cleanup when any devices > which need the module are busy. Having the device busy, but the > module removed, would cause segmentation faults or kernel panics. > MOD_IN_USE can be influenced via ioctl. > > Now I don't understand why i shouldn't use the macros. I've read now > a few times that i'll have to (i remember also lkmpg gives the advice > to use them, the book linux-kernelprogramming (german) gives the advice, > too). Who can lead me out ? Every code, where there is a reason to call MOD_INC/DEC_USE_COUNT, is broken, because there is a race. When there is a module M that provides some function (say F), the count for M must be incremented _before_ the first instruction of F is executed and decremented only _after_ the last instruction of F has finished. Thus you have to make sure that anyone who calls F increments the use count. For filesystems, devices and the like, there is always on owner field somewhere that is used by generic code to increment use count of module that implements the file/device/... For functions used by other module by means of dynamick linking, the linker takes care of that. Any other entry point has a problem, but there should not be any possibility for other entry point. (Modules can't sanely add syscalls). ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@ucw.cz> -- Kernelnewbies: Help each other learn about the Linux kernel. Archive: http://mail.nl.linux.org/kernelnewbies/ FAQ: http://kernelnewbies.org/faq/
