Good morning!I believe we have found a bug in the NFS kernel area. The "bug" is a leak of a file handle where the NFS client never tells the server to close the file. The problem is very similar to one we had reported and got a fix for previously. We are using that patch, but ran in to another case where the client sends out an OPEN_DOWNGRADE but never sends a CLOSE.
Attached is a simple c program that we have been able to reproduce the bug with, along with a packet capture of what we see on the wire.
To reproduce the bug: -compile the c code -execute the c code with: ./test ; cat testfile3 > /dev/nul-now if we try to remove the file we get a file in use error (server is using mandatory locking)
Things to note:-if you just run the program without the immediate cat'ing of the file, the bug does not happen
suggesting a timing issue-If you alter the program so the code mimics the cat of the file, the bug does not happen (ie, add an open, read file, close to the code). -If you run the program as described above, and then run it again without the "; cat testfile3 > /dev/nul", the kernel squeaks out the file close to the server when the code does the close.
The attached packet capture is us doing: ./test ; cat testfile3 > /dev/null rm testfile3 ./test rm testfile3 where we are denied the rm the first time, but not the second. Thanks James
Attachment:
test.c
Description: application/softgrid-c
<<attachment: nfsbug.zip>>
