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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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