Bug 625078

+++ This bug was initially created as a clone of Bug #511901 +++

Description of problem:

Parallels Virtuozzo Containers/OpenVZ linux kernel team found that sometimes NFS temporary (silly-rename: .nfs0000*) files can be left on a filesystem when no process has them open.
Kernel version affected: checked 2.6.18-8.el5, 2.6.18-128.2.1.el5 x86_64, both are affected.

Reproducer source (test_nfs_exit_thr4.c) is in attach.
Brief description: create a thread which will create and unlink files in a cycle, then exit main thread without waiting for children.

How to reproduce:

[root@tom nfs]# uname -a
Linux HOSTNAME 2.6.18-128.2.1.el5 #1 SMP Wed Jul 8 11:54:47 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
[root@tom ~]# mount NFSSERVERNAME:/vz/export/tom /mnt/nfs/
[root@tom ~]# cd /mnt/nfs/
[root@tom nfs]# mount |grep nfs
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
NFSSERVERNAME:/vz/export/tom on /mnt/nfs type nfs (rw,addr=NFSSERVERIP)
[root@tom nfs]# gcc /tmp/test_nfs_exit_thr4.c -pthread -o /tmp/test
[root@tom nfs]# ls -Flaio
total 12
13403720 drwxr-xr-x  2 root 4096 Jul 15 18:00 ./
 1498497 drwxr-xr-x  3 root 4096 Jul 15 16:40 ../
[root@tom nfs]# /tmp/test
main: exit ok!
[root@tom nfs]# /tmp/test
main: exit ok!
[root@tom nfs]# ls -Flaio
total 12
13403720 drwxr-xr-x  2 root 4096 Jul 15 17:55 ./
 1498497 drwxr-xr-x  3 root 4096 Jul 15 16:40 ../
 13403721 ----------  1 root    0 Jan  5  1970 ashfilecs2QiM
 13403722 -rw-------  1 root    0 Jul 15 17:55 .nfs0000000000cc864a000005a8
[root@tom nfs]# ps axf |grep test
 3147 pts/0    S+     0:00          \_ grep test

Note1: ashfiles* files left are ok, they were created but not unlinked before the thread killed, but .nfs* files left seems to be wrong.
Note2: the reproducer does not trigger .nfs* files appearance in 100% cases but still very often.

--- Additional comment from jlayton on 2010-06-09 10:37:44 EDT ---

FWIW, I've been able to reproduce this on 2.6.34-ish kernels too. The race window there seems to be slightly smaller for reasons that aren't exactly clear to me, but it's still present there.

--> CLONING FOR RHEL-6

--- Additional comment from jlayton on 2010-06-28 14:26:46 EDT ---

cc'ing Trond in case he has thoughts on this...

We can't easily make this function use an uninterruptible sleep. What we may actually need to do is make the rename asynchronous, and have the sillyrename thread wait on its completion. That way, if the thread is killed, everything still should proceed to completion.