[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak?
From:       Michael Riepe <michael () stud ! uni-hannover ! de>
Date:       2000-08-31 23:18:08
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]