[linux-cifs-client] broken client-side caching - PATCH for 2. 4 kernel, possibly still bug in 2.6?

Vince Negri vnegri at asl-electronics.co.uk
Thu Jan 13 11:28:09 GMT 2005


Hi all again,

I managed to track down and fix the problem on my 2.4.21 kernel
with a change to cifs/file.c. See attached patch against the
1.20c version as shipped on the project site.

The bug occured as the result of the following set of steps:

1) Linux client opens and reads a file on w2k3 server share.
(fills page cache)
2) Linux client closes file.
3) Windows client modifes the file (date and size change)
4) Linux client scans the file's directory, invoking cifs_readdir().
This invokes cifs_filldir() for each file in the directory,
including the one that has been modified.
5) cifs_filldir() calls fill_in_inode() for the file, which ends up
updating the timestamp and length info for the inode, *but* does not
first check to see if they have changed. As a result, the inode's
timestamp/size info are up to date, but the page cache has not
been invalidated - oops

6) A subsequent open of the file does not trigger a re-read over
the network, because the inode time/date info is already "correct".

In particular, this code in cifs_open gets "fooled":

     temp = cifs_NTtimeToUnix(le64_to_cpu(buf->LastWriteTime));
     if(timespec_equal(&file->f_dentry->d_inode->i_mtime,&temp) &&
       (file->f_dentry->d_inode->i_size ==
(loff_t)le64_to_cpu(buf->EndOfFile))) {
         cFYI(1,("inode unchanged on server"));
     } else {



Looking at the latest 2.6 kernel code, it appears that the bug may
still exist in file.c - at least, no page cache invalidation has been
added to fill_in_inode(). But changes elsewhere may have fixed the
problem in a different way? Comments appreciated.



 <<cifs-patch>> 

Vince
Legal Disclaimer: Any views expressed by the sender of this message are
not necessarily those of Application Solutions Ltd. Information in this 
e-mail may be confidential and is for the use of the intended recipient
only, no mistake in transmission is intended to waive or compromise such 
privilege. Please advise the sender if you receive this e-mail by mistake.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cifs-patch
Type: application/octet-stream
Size: 2188 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20050113/97e32835/cifs-patch.obj


More information about the linux-cifs-client mailing list