lkml.org 
[lkml]   [2000]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [NFS] [PATCH] Re: grow_inodes: inode-max limit reached - how to find/fix the inode leak?
From
>>>>> " " == 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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.044 / U:4.612 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site