Bug 577378

Created attachment 402931 [details]
Patch backported from RHEL-5

Description of problem:

When a RHEL-4 NFSv3 client performs a READDIRPLUS operation at the server, the file attributes for existing cached files are not updated. In this case if an existing file name that points to a regular file gets changed into a symlink or a directory, it is not noticed until an actual stat() call forces an NFS GETATTR on the specific file.

Certain system calls, such as getdents(), return file type information that is based on existing cached file attributes. When a certain directory entry changes it's type, the parent directory contents are refreshed given its mtime change, but the actual directory entry information is not. So the getdents() call returns stale information, and this can keep happening for several hours, regardless of "noac" or "actimeo" settings, since nothing will cause each specific dentry to be updated even if the READDIRPLUS reply provides the needed information.

Certain core utilities, such as find(1), use getdents() and get fooled by this behavior.

This was fixed early on in RHEL-5 in a monster patch attributed to bug 242975. I found the specific upstream commit, the large RHEL-5 commit, and factored out and backported only the changes to nfs_readdir_lookup that are relevant.

Patch applies cleanly to latest RHEL-4 sources and fixes the issue. I'll also attach a tiny "getdents.c" program (from the getdents manpage) that can be used to verify this very easily. Notice a simple "ls -l" does not trigger it since ls(1) does an actual stat() on each directory entry.

Version-Release number of selected component (if applicable):

kernel-2.6.9-89.EL

How reproducible:

Always.

Steps to Reproduce:

1. Mount an NFS volume using RHEL-4, say on /mnt

2. Run the getdents program on a test directory containing a few entries, such as "getdents /mnt/test/"

3. Notice the file types listed for each directory entry

4. At the server or in another NFS client, change a certain directory entry to another type, such as "rm -f /mnt/test/foobar ; mkdir /mnt/test/foobar"

5. Run "getdents /mnt/test/" in the RHEL-4 client again, and notice that it still lists "/mnt/test/foobar" as a file, instead of a directory.

Example:

$ ./getdents /mnt/test/
--------------- nread=80 ---------------
i-node#  file type  d_reclen  d_off   d_name
 1261573  directory    24  796079690  .
 1261569  directory    24  817063672  ..
 1261576  symlink      32 2147483647  foobar

[ At the server, remove the symlink and create a file with the same name ]

$ ./getdents /mnt/test/
--------------- nread=80 ---------------
i-node#  file type  d_reclen  d_off   d_name
 1261573  directory    24  796079690  .
 1261569  directory    24  817063672  ..
 1261576  symlink      32 2147483647  foobar

[ The RHEL-4 NFS client did not perceive the change ]

$ stat /mnt/test/foobar 
  File: `/mnt/test/foobar'
  Size: 0    Blocks: 0    IO Block: 4096    regular empty file
...

[ Explicit stat() issues an explicit GETATTR ]

$ ./getdents /mnt/test/
--------------- nread=80 ---------------
i-node#  file type  d_reclen  d_off   d_name
 1261573  directory    24  796079690  .
 1261569  directory    24  817063672  ..
 1261576  regular      32 2147483647  foobar

[ Only after the explicit stat() the type was updated ]

It is easy to see in wireshark that the RHEL-4 NFS client does notice the change in the directory's mtime, and issues a READDIRPLUS, which does return updated information for "foobar", but the nfs_readdir_lookup() function does not use it.

Actual results:

getdents() returns stale type information in the dirent->d_type fields.

Expected results:

getdents() returns updated type information in the dirent->d_type fields.

Additional info:

Customer is also testing the patch.