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

[Jeff Layton]

On Fri, 19 Dec 2008 10:48:07 -0600
Steven French <sfrench at us.ibm.com> wrote:

> he SMB Write has at least been issued before the close which is 
> all that is needed for it to succeed on the server ... depending on the 
> file offset (e.g. writing way beyond end of file) it could of course take 
> a long time to return success to the client, but it will eventually 
> succeed as long as it gets on the wire first (even if the write is not 
> complete, it on the wire by the time we give up on it and send the SMB 
> close) ... what we don't want to do is let the SMB Close get in to the 
> server ahead of the SMB Write which depends on the handle
> 

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.

-- 
Jeff Layton <jlayton at redhat.com>