Messages in this thread |  | | Date | Fri, 1 Sep 2000 11:40:31 +0200 (CEST) | Subject | Re: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak? | From | Trond Myklebust <> |
| |
>>>>> " " == Michael Riepe <michael@stud.uni-hannover.de> writes:
>> Ugh. In that case, my personal preference would be to make >> nlm_release_file() grab the semaphore, then call another >> routine to do f_count-- and possible file cleanup which could >> also be called by nlmsvc_traverse_shares(). Call it >> nlm_put_file() if you like 8-).
> nlm_release_file() *does* grab the semaphore. That's the > problem.
Which is why I'm proposing a solution: to split it into 2 functions. 1st function does the semaphore manipulations and calls 2nd function which does the f_count--, nlm_delete_file()...
The second function can be called by any other creature already holding the semaphore to safely decrement f_count. That way we don't fill the lockd stuff with loads of different routines that may end up doing --f_count wrongly (like put_file(file, 0); will do).
> Adding or removing blocks or locks does not affect f_count at > all. There ist one function that changes f_count when it > removes a block, but it is never called, at least not in 2.2.x.
Look again. With exception of nlmsvc_proc_null(), every single call to a nlmsvc_proc_*() routine will do nlmsvc_lookup_file() which does change f_count.
--
In any case, the point is we don't want to have loads of different routines doing the work of nlm_release_file(). That's going to give rise to unnecessary maintenance issues whenever we want to make changes.
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |