Re: broken cifsFileInfo handling in cifs_reopen_file codepath

On Fri, 18 Sep 2009 12:10:35 -0500
Steve French <[email protected]> wrote:

> I thought you and I had crawled through this with Shirish early in the
> summer, but I agree that the reopen path is hard to follow but it
> should be easy to prove whether it leaks on reconnect.  I agree with
> the general point though - we can't reallocate a file struct on
> reconnect in the posix path and that seems straightforward
> 

I don't recall walking through this particular chunk of code -- we did
discuss the open on lookup stuff, but that's only peripherally related
to this...

Note that this is actually a little worse than I originally stated.
Each cifsFileInfo struct holds an inode reference. So you're probably
leaking inode references in this codepath too.

The fix doesn't look too hard. You need to fix cifs_posix_open so that
it doesn't automatically create a cifsFileInfo itself. Either pass one
into it that's already allocated, or (even better) just have the
callers fill it out. It would also be good to consolidate
cifs_fill_fileinfo and cifs_init_private since they basically do the
same thing.

-- 
Jeff Layton <[email protected]>