[linux-cifs-client] close-to-open cache consistency and cifs

[Jeff Layton]

> > 
> > Is it possible though for you to do this wait loop, and when you come
> > out the needs_reconnect or invalidHandle is set (i.e., maybe you raced
> > with a reconnection event in the middle of writeback). In that case, a
> > close would not be issued, even though another task (maybe kswapd?)
> > could reopen the file to do I/O to it.
> > 
> > The problem is that we want to ensure that the filehandle is actually
> > closed before cifs_close returns so I don't think we can get away with
> > adding some refcounting and having the last user issue the close.
> > 
> > It seems like we should have cifs_close wait indefinitely for
> > wrtPending to go to 0 here. It also seems like this needs a proper
> > waitqueue as well so we're able to wake up as soon as wrtPending drops
> > to 0.
> > 

On Fri, 19 Dec 2008 13:20:06 -0600
Steven French <sfrench at us.ibm.com> wrote:

> I didn't think the code could reopen a file that is marked closing (close 
> pending).
>

Then once cifs_close marks it closePend, there had better not be any more
dirty pages attached to the inode, correct? Once we mark it close pending
then there may be no more opportunity to write out the data because we
can't reopen the file. cifs_close though seems to assume that it is
possible.

It does check tcon->needs_reconnect before it starts looking through the
loop, but that seems racy. Just because that's false doesn't mean that the
filehandle is still good.


Essentially I'm looking at this because I'd like to see us try to use
posix locking as cache consistency points similar to how NFS works.
i.e.: revalidate the file data on lock and flush all the dirty pages
for an inode on unlock. Before I do that though, I want to make sure we
have the open/close cache consistency correct as well.

I need to stare at this code some more. I don't have it completely worked
out yet, but there seem to be possible races here...

-- 
Jeff Layton <jlayton at redhat.com>