NFS v4.0: Stale data after file is renamed while another process has an open file handle

[Stan Hu]

NOTE: This bug has been fixed in the upstream mainline kernel via https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=be189f7e7f03de35887e5a85ddcf39b91b5d7fc1 and merged in the latest NFS client patches in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=c7a2c49ea6c9eebbe44ff2c08b663b2905ee2c13.

The full patchset is here: https://marc.info/?l=linux-nfs&m=153816500525563&w=2

I'm repeating the report I sent to the NFS maintainers on the mailing list:

On Ubuntu 16.04 (4.4.0-130) with NFS v4.0, I'm seeing an issue where
stale data is shown if a file remains open on one machine, and the
file is overwritten via a rename() on another. Here's my test:

1. On node A, create two different files on a shared NFS mount:
"test1.txt" and "test2.txt".
2. On node B, continuously show the contents of the first file: "while
true; do cat test1.txt; done"
3. On node B, run a process that keeps "test1.txt" open. For example,
with Python, run:
     f = open('/nfs-mount/test1.txt', 'r')
4. Rename test2.txt via "mv -f test2.txt test1.txt"

On node B, I see the contents of the original test1.txt indefinitely,
even after I disabled attribute caching and the lookup cache. I can
make the while loop in step 2 show the new content if I perform one of
these actions:

1. Run "ls /nfs-mount"
2. Close the open file in step 3

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1802585

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Salisbury (jsalisbury)]

I built a test kernel with commit be189f7e7f03. The test kernel can be downloaded from:
http://kernel.ubuntu.com/~jsalisbury/lp1802585

Can you test this kernel and see if it resolves this bug?

Note about installing test kernels:
• If the test kernel is prior to 4.15(Bionic) you need to install the linux-image and linux-image-extra .deb packages.
• If the test kernel is 4.15(Bionic) or newer, you need to install the linux-modules, linux-modules-extra and linux-image-unsigned .deb packages.

Thanks in advance!

[Stan Hu (stanhu)]

Looks good to me!

[Bryan Quigley (bryanquigley)]

I was able to reproduce this. Minor note, that you need to specify vers=4.0 in the mount options, nfs 4.1+ appears to not be affected by this.

[Bryan Quigley (bryanquigley)]

I was also able to reproduce this on Eoan by specifying vers=4.0 - where I thought it should be fixed.

I was able to confirm that the -proposed 4.15 kernel (I tested xenial HWE version) does have the fix and it works:https://lists.ubuntu.com/archives/xenial-changes/2019-August/025318.html

[Bryan Quigley (bryanquigley)]

My reproducer for Disco+ is a different bug. I get input/output errors very quickly once specifying nfs vers=4.0. If you don't specify it, it works fine.

[Bryan Quigley (bryanquigley)]

This was fixed in the latest 4.15 kernels (linux-hwe 4.15.0-60.67)