Messages in this thread |  | | Date | Fri, 1 Sep 2000 00:37:21 +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:
> On Thu, Aug 31, 2000 at 03:23:43PM +0200, Trond Myklebust > wrote: >> Your patch does not seem correct to me. IMO you should rather >> be calling nlm_release_file() in both cases where you applied >> 'put_file()'.
> No. In the first of two cases, lockd will call > nlm_release_file() on its own when the function returns. In
The call in nlmsvc_unshare_file() is in order to clear the f_count from nlmsvc_share_file(). That in nlmsvc_proc_unshare() clears the f_count from nlmsvc_retrieve_args().
> the second case, we're being called from inside > nlm_traverse_files(), which holds a lock on the file table -- > nlm_release_file() would wait forever.
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-).
However, the test for min_count is wrong. In both cases you are trying to clear the f_count that was incremented in nlmsvc_share_file(). Since shares and locks are invisible to one another, I'm quite free to have an ordinary block on the same file thus screwing up your f_count test.
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/
|  |