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

[Steven French]

It is not obvious to me why posix locking would/should have any relation 
to clean/dirty pages.   Other clients don't use posix locks for this, so 
the only chance we would have to do this safely would be in an all Linux 
environment (perhaps optional).    If NFS uses posix locks for this, today 
we are more conservative than nfs, since we flush non-cacheable files on 
every write (and NFSv3 can't do safe caching).


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 02:14 PM

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






> > 
> > 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>