Created attachment 4998 [details]
strace of smbd of the writing client while reproducing this bug

Created attachment 4999 [details]
strace of smbd of the locking (reading) client while reproducing this bug

Created attachment 5000 [details]
Network traffic between server and both clients while reproducing this bug

Created attachment 5001 [details]
strace of the writing process on (wireshark) client W while reproducing this bug

In the jitter, you can find this line:

12076 20:43:55.104443 open("/mnt/homes/\303\226ffentlich/joerg/x-smb-network.dump", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 8

i.e. the client write access to the locked file.

I don't see any fcntl lock requests in your strace. You do know that POSIX locks are *advisory* don't you. I.e. Samba won't prevent a POSIX client writing to a file - they client has to coordinate the locks themselves with fcntl calls.

Jeremy.

(In reply to comment #5)
> I don't see any fcntl lock requests in your strace. You do know that POSIX
> locks are *advisory* don't you. I.e. Samba won't prevent a POSIX client writing
> to a file - they client has to coordinate the locks themselves with fcntl
> calls.

I don't know where this Lock in smbstatus comes from, but to me it doesn't look like the application installs this lock. Start less on a client and then run smbstatus. At me, I get a file lock, while less does nothing else than open, read and keeping the file open. It seems this is enough to get an entry in the file lock section of smbstatus. So these locks aren't handled on application level.

And even if this is a POSIX lock and the application (wireshark) misbehaves, the client R should get access to the new file or get a hint that the file has changed.

I don't see any locks in your trace. Don't be confused by the "Locked files" comment in smbstatus. This should really say "Open files". In fact I think I'll change it....
Jeremy.

But trying to change a "locked/opened" file from a Windows client results in access denied. And when a Windows client has opened a file I can't write to this file on the linux client.

And even if all this is fine, why does the linux client R not get the file update after client W has changed the file? (See the md5sums in the bug report) Is this a bug in the linux client?

Created attachment 5010 [details]
Network traffic with client R == Linux && client W == Windows

When opening a file with less on a Linux client (== client R) and try to save something to this file on a Windows XP client (== client W) then the Windows client refuses to save the file.

# smbstatus

Samba version 3.4.3
PID     Username      Group         Machine                        
-------------------------------------------------------------------
9138      joerg         adm           __ffff_10.10.10.26 (::ffff:10.10.10.26)
13067     joerg         adm           muffi        (::ffff:10.10.10.21)

Service      pid     machine       Connected at
-------------------------------------------------------
all-homes    13067   muffi         Wed Nov 25 17:06:30 2009
projects     9138   __ffff_10.10.10.26  Wed Nov 25 12:29:35 2009
all-homes    9138   __ffff_10.10.10.26  Wed Nov 25 12:29:35 2009

Locked files:
Pid          Uid        DenyMode   Access      R/W        Oplock           SharePath   Name   Time
--------------------------------------------------------------------------------------------------
9138         1000       DENY_NONE  0x81        RDONLY     NONE             /home   joerg/file   Wed Nov 25 17:20:41 2009
13067        1000       DENY_NONE  0x100081    RDONLY     NONE             /home   joerg   Wed Nov 25 17:17:19 2009
13067        1000       DENY_NONE  0x100081    RDONLY     NONE             /home   .   Wed Nov 25 17:17:16 2009

This differs from the behaviour explained in the bug report. A Linux client can change the file, while a Windows client can't.

The Windows behaviour is understandable. Windows tries to open the file with DENY_ALL (or rather FILE_SHARE set to 0). As the file is already open, Samba denies this second open. Linux clients don't do that.

The fact that a second client does not see the changes made by the first one is something I would like Jeff Layton to look at. Re-assigning the bug to him.

Volker

Thanks for the bug report. Sounds like there's a problem with the revalidation code -- i.e. we're getting new attributes for the inode but not invalidating the cache. Then when the client goes to read the file again, it trusts that the cache is OK because it doesn't notice the timestamp changes.

Can you outline exactly how you're reproducing that problem?

I can reproduce this bug this way:

shell-1% echo 1 > file
shell-1% less 1

shell-2% ssh remote-host echo 2\> file\; cat file
2
shell-2% cat file
1

Created attachment 5062 [details]
test patch 1 -- allow cifs to invalidate cached data for open files

Ahh ok. I think I see the problem...

CIFS currently doesn't allow the kernel to invalidate the pagecache for files that it has open. It's not clear to me why this is the case.

This patch changes that behavior, but note that it's completely untested. The patch is also racy. It's easily possible for it to end up invalidating pages that were dirtied after the writeback. Fixing this the right way will mean making sure that can't happen.

Still though, it would be good to have you test this patch to make sure we're on the right track here. If you have a non-critical place to do so, please test it and let me know if it fixes the issue.

In the example above, patching just the "reader" client should be sufficient.

Adding Steve and Shirish...

I think this problem is due to the fact that CIFS doesn't invalidate the cache on open files. The patch I attached is just for testing. A real patch will probably need to convert this code to use invalidate_inode_page2 and check the return value.

We'll probably also need to change this code not to do the invalidation in d_revalidate but instead just flag the inode for invalidation when an operation needs it -- on reads in particular, but probably a few other calls too.

(In reply to comment #13)
> Created an attachment (id=5062) [details]
> test patch 1 -- allow cifs to invalidate cached data for open files
> 
> Ahh ok. I think I see the problem...

But his patch fixes the problem only partly. With this patch I get the new content after closing less. But while less keeps the file open, a cat in a second terminal shows the old content.

This works:
shell-1% echo 1 > file
shell-1% less file

shell-2% ssh remote-host echo 2\> file\; cat file
2
shell-1% <close less>
shell-1% cat file
1

This doesn't work:
shell-1% echo 1 > file
shell-1% less file

shell-2% ssh remote-host echo 2\> file\; cat file
2
shell-2% cat file # less is still open in shell-1
1

I can't recreate this problem with fairly recent cifs client and 
[root@linux-nfs2 smb_t]# /usr/sbin/smbd -V
Version 3.0.28-0.el5.8
what am I missing?

-------------------------------------------------------------------------------
cifstest6:/mnt/smb_b # tty
/dev/pts/0

cifstest6:/mnt/smb_b # mount

//linux-nfs2/smbt on /mnt/smb_b type cifs (rw,mand)

cifstest6:/mnt/smb_b # pwd
/mnt/smb_b

cifstest6:/mnt/smb_b # echo 1 > file3
cifstest6:/mnt/smb_b # less file3

1
file3 lines 1-1/1 (END)

------------------------------------------------------------------------------

cifstest6:/mnt/smb_b # tty
/dev/pts/2

cifstest6:/mnt/smb_b # pwd
/mnt/smb_b

cifstest6:/mnt/smb_b # ssh linux-nfs2.  echo 2 > file3; cat file3
root@linux-nfs2's password:
2
-------------------------------------------------------------------------------

cifstest6:/mnt/smb_b # cat file3
2

Forgot to run this command,  cat file3 in pts2 with or without less keeping
the file open still displays correct contents, i.e. 2 and not 1.

(In reply to comment #16)
> I can't recreate this problem with fairly recent cifs client and 
> [root@linux-nfs2 smb_t]# /usr/sbin/smbd -V
> Version 3.0.28-0.el5.8
> what am I missing?

> cifstest6:/mnt/smb_b # ssh linux-nfs2.  echo 2 > file3; cat file3

Did you really run this command? Then the only thing you did on the remote side is 'echo 2.' The redirect (i.e. the write) and the cat happend on the client that runs less. But you have to modify the file on the remote side.

Do you access the filesystem on the remove side via cifs? What I did was accessing the file from two different clients. I've never accessed the filesystem exported by Samba.

# smbd --version
Version 3.4.3

(In reply to comment #18)
> > cifstest6:/mnt/smb_b # ssh linux-nfs2  echo 2 > file3; cat file3
> Did you really run this command? Then the only thing you did on the remote side

Yes, I have cd'ed to the mounted directory and doing all the writing.
I did check the contents of the file on the server as well and it is 
the second echo i.e. 2.

Me too. I can't reproduce it with 3.0, but with 3.4. A second problem is
that I can't write to files on the 3.0 server.

% cat /mnt/other/test
1
% echo 2 > /mnt/other/test
zsh: no such file or directory: /mnt/other/test
% ls -l /mnt/other/test
-rwxrwSrwx 1 root root 2 Dec  8 19:10 /mnt/other/test

Hence, I have to do the access with smbclient.

% grep /mnt/home /proc/mounts 
//cifs-homes.net.de/all-homes /mnt/home cifs rw,mand,nosuid,nodev,relatime,unc=\\cifs-homes.net.de\all-homes,username=joerg,domain=ATeO,addr=10.10.10.6,posixpaths,serverino,acl,rsize=16384,wsize=57344 0 0
% echo 1 > /mnt/home/joerg/test
% less /mnt/home/joerg/test
---------------------------------------------------
% echo 2 > /tmp/test
% cd /tmp; PAGER=cat smbclient -U joerg //cifs-homes.net.de/all-homes -D joerg -c 'more test; put test; more test'
Enter joerg's password: 
Domain=[ATEO] OS=[Unix] Server=[Samba 3.4.3]
getting file \joerg\test of size 2 as /tmp/smbmore.Zkfs9Y (0,2 KiloBytes/sec) (average 0,2 KiloBytes/sec)
1
putting file test as \joerg\test (0,1 kb/s) (average 0,1 kb/s)
getting file \joerg\test of size 2 as /tmp/smbmore.wvHMmt (0,2 KiloBytes/sec) (average 0,2 KiloBytes/sec)
2
% cat /mnt/home/joerg/test
1

Now, a different server:

% grep /mnt/other /proc/mounts
//saturn93b/www /mnt/other cifs rw,mand,nosuid,nodev,relatime,unc=\\saturn93b\www,username=poolteam,addr=10.10.10.7,posixpaths,serverino,acl,rsize=16384,wsize=57344 0 0
% echo 1 > /mnt/other/test
% less /mnt/other/test
---------------------------------------------------
% echo 2 > /tmp/test
% cd /tmp; PAGER=cat smbclient -U poolteam //saturn93b/www -c 'more test; put test; more test'
Enter poolteam's password: 
Domain=[INFONET] OS=[Unix] Server=[Samba 3.0.23d-6-1083-SUSE-SL10.2]
getting file \test of size 2 as /tmp/smbmore.Bpehly (0,5 KiloBytes/sec) (average 0,5 KiloBytes/sec)
1
putting file test as \test (0,5 kb/s) (average 0,5 kb/s)
getting file \test of size 2 as /tmp/smbmore.t76xwe (1,0 KiloBytes/sec) (average 0,7 KiloBytes/sec)
2
% cat /mnt/other/test
2

I've tried to reproduce this in several ways and have had no luck. The server is running:

samba-3.4.2-47.fc12.x86_64

...I've tested this with the following kernels:

kernel-2.6.31.9-174.fc12.x86_64
kernel-2.6.32.2-18.fc13.x86_64

...I'm afraid I don't have anything older handy. I noticed in the original description that one of the hosts is running a 2.6.28 kernel. Can you reproduce this when that client is running a newer one?

Also, it might be helpful to see if you can reproduce this on a non -rc kernel. Perhaps this was a bug fixed in the -rc phase?

(In reply to comment #21)
> I've tried to reproduce this in several ways and have had no luck. The server
> is running:
> 
> samba-3.4.2-47.fc12.x86_64
> 
> ...I've tested this with the following kernels:
> 
> kernel-2.6.31.9-174.fc12.x86_64
> kernel-2.6.32.2-18.fc13.x86_64

me too. My server is running Samba 3.4.3 and my client Linux 2.6.32-trunk-686 (Debian-Kernel).

> ...I'm afraid I don't have anything older handy. I noticed in the original
> description that one of the hosts is running a 2.6.28 kernel.

In the meantime, I've updated all client systems. I don't have a system with 2.6.28.

I think this bus is resolved.

Ok then...

Closing bug with a resolution of FIXED. Please reopen if it returns.