[linux-cifs-client] broken cifsFileInfo handling in cifs_reopen_file codepath
Jeff Layton
jlayton at redhat.com
Fri Sep 18 11:55:34 MDT 2009
On Fri, 18 Sep 2009 12:10:35 -0500
Steve French <smfrench at gmail.com> 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 <jlayton at redhat.com>
More information about the linux-cifs-client
mailing list