Testing against NetApp filer, running connectathon lock test test13 and then test14 in sequence: Test #13 - Check locking and mmap semantics. Parent: 13.0 - F_TLOCK [ ffe, ENDING] PASSED. Parent: 13.1 - mmap [ 0, 1000] WARNING! Parent: **** Expected EAGAIN, returned success... Parent: 13.2 - F_ULOCK [ 0, ENDING] PASSED. Parent: unmap testfile. Parent: 13.3 - mmap [ 0, 1000] PASSED. Parent: 13.4 - F_TLOCK [ ffe, ENDING] PASSED. Parent: Closing testfile. Test #14 - Rate test performing I/O on unlocked and locked file. tlock: open: No such file or directory Parent: Closing testfile. ** PARENT pass 1 results: 4/4 pass, 1/1 warn, 0/0 fail (pass/total). Child: Closing testfile. ** CHILD pass 1 results: 0/0 pass, 0/0 warn, 0/0 fail (pass/total). ...the file can't be created for test14 because test 13 hasn't actually closed and deleted the file. When the program exits, however, the file is deleted as part of sys_exit. I see no evidence that cifs_close is even being called as part of the explicit close call, so the delete then fails. I suspect this is a refcounting bug of some sort with files that have been mmapped...
Created attachment 305379 [details] netapp lock test capture
I think we've only seen this against this netapp filer because it doesn't implement a particular Trans2 call that windows does. We end up not being able to delete or rename by FID and so the file ends up lingering around longer than usual.
Adding steve. I opened this as a RHEL5 bug, but I suspect that it's an upstream problem as well (not yet confirmed though).
It turns out that this is expected behavior. The reproducer does not unmap the file before (or after) closing it. This is arguably a bug in lock test 13 -- the main thing that keeps us from passing the test is the fact that the silly-rename attempt doesn't work. If the netapp server supported the calls that we needed to make the silly rename work (or just allowed us to delete an open file) then this wouldn't be a problem.
Opened netapp case #2000291719 to see if we can get them to fix this. No response as of yet.
Got an email from them that they've considered this an RFE: I'm sending this email to let you know that an RFE(request for enhancement) has been filed to support the file rename calls you specified. The RFE number is 326641.
Closing this bug out since there's little we can do for it.