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: Fri Sep 01 2000 - 08:45:35 EST


On Fri, Sep 01, 2000 at 11:40:31AM +0200, Trond Myklebust wrote:
[...]
> > 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).

Heck no, it won't. I had `put_file(file, 1);' in nlmsvc_traverse_shares()
before, and it complained.

Have you looked at put_file() close enough? It's an inline function,
and it's basically `--f_count' plus my paranoia. Again, feel free to
remove it and simply decrement f_count if you like that better. Or put
all f_count manipulations into a pair of new functions. But please
stop arguing with me -- I only found the bug, fixed it, reported it,
and now I will say good-bye and move on. I guess Linus & others are
already becoming bored... sorry for that.

> > 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.

Yes, but the call to nlm_release_file() on return from nlmsvc_proc_*()
will decrement it again. In lockd's main event loop, no changes are
visible unless you add or remove a share.

> 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
> changes.

Who is "we"?

Excuse me, but lockd is so full of `maintenance issues' (*cough*) that I
would never have touched it if there hadn't been this bug. Maybe that's
the reason why the bug has been there for such a long time and nobody
cared to fix it, although there has been at least one report 5 months ago.

Did I hear `thank you'?

Ciao,

-- 
 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/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:11 EST