Messages in this thread |  | | Date | Fri, 1 Sep 2000 01:18:08 +0200 | From | Michael Riepe <> | Subject | Re: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak? |
| |
On Fri, Sep 01, 2000 at 12:37:21AM +0200, Trond Myklebust wrote: > >>>>> " " == 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().
Yes. That one was missing.
> That in nlmsvc_proc_unshare() clears the f_count from > nlmsvc_retrieve_args().
Correct. The calling sequence is
nlmsvc_retrieve_args() /* increments */ nlmsvc_unshare_file() /* decrements if share is removed */ nlm_release_file() /* decrements */
so f_count will be at least 2 when nlmsvc_unshare_file() finds a share to remove. In nlmsvc_traverse_shares(), the surrounding retrieve/release calls are missing, so the minimum f_count is 1.
> > 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-).
nlm_release_file() *does* grab the semaphore. That's the problem.
> 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.
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.
The min_count test is irrelevant (TM) anyway. In fact, I could have used a simple `file->f_count--;' instead of `put_file();' (feel free to do that yourself), but I'm paranoid and wanted lockd to complain if something goes wrong. The min_count values are correct, however.
-- Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de> "All I wanna do is have a little fun before I die" - 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/
|  |