On Thu, Jun 10, 2004 at 18:07:16 +0530, aksingh@hss.hns.com wrote: > Just a doubt on this -- what happens, when an application using the module > crashes. The application had done a MOD_INC_USE_COUNT and then it crashed, > so the module stays for ever unless the pc is rebooted . The module may be > working perfectly alright, just that it cannot eb removed. No. It's NOT the application doing MOD_INC_USE_COUNT. It is kernel. > This can prove to be a problem for say a char device. > > someone opens it, MOD_INC_USE_COUNT is incremented in the open() call, then > the application that opened it crashes. so the module cannot be removed. > Now someone starts that process again, and calls the open function again, > will it work. It would be just the same problem for filesystems, sockets, pipes, everything... No, it is not a problem. The thing is, that the use count is held by the file descritor, which is reference-counted. When application's file descriptor array is freed (during destruction of it's context). When it's refcount goes zero (several processes may use it), the generic device close calls close from your device descriptor and decrements module refcount. > It will but then this shows that doing something like this -- if > (MOD_IN_USE) return -EBUSY in the char device open() function might be a > foolish thing to do, even if u assume that one and only one user level > process would be accessing your module. > > regards > Amit ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@ucw.cz>
Attachment:
signature.asc
Description: Digital signature
