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

[Steven French]

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


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com



Jeff Layton <jlayton at redhat.com> 
12/19/2008 11:19 AM

To
Steven French/Austin/IBM at IBMUS
cc
linux-cifs-client at lists.samba.org, 
linux-cifs-client-bounces+sfrench=us.ibm.com at lists.samba.org, "Shirish 
Pargaonkar" <shirishpargaonkar at gmail.com>, ssorce at redhat.com
Subject
Re: [linux-cifs-client] close-to-open cache consistency and cifs






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>