This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 446434 - cifs silly-rename doesn't work against netapp servers
cifs silly-rename doesn't work against netapp servers
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Jeff Layton
Red Hat Kernel QE team
Depends On:
  Show dependency treegraph
Reported: 2008-05-14 12:11 EDT by Jeff Layton
Modified: 2014-06-18 03:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-06-23 12:36:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
netapp lock test capture (1.72 KB, application/octet-stream)
2008-05-14 12:11 EDT, Jeff Layton
no flags Details

  None (edit)
Description Jeff Layton 2008-05-14 12:11:38 EDT
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...
Comment 1 Jeff Layton 2008-05-14 12:11:38 EDT
Created attachment 305379 [details]
netapp lock test capture
Comment 2 Jeff Layton 2008-05-14 12:16:04 EDT
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
Comment 3 Jeff Layton 2008-05-14 12:26:39 EDT
Adding steve. I opened this as a RHEL5 bug, but I suspect that it's an upstream
problem as well (not yet confirmed though).
Comment 4 Jeff Layton 2008-05-14 16:13:24 EDT
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.
Comment 5 Jeff Layton 2008-11-04 12:58:59 EST
Opened netapp case #2000291719 to see if we can get them to fix this. No response as of yet.
Comment 6 Jeff Layton 2008-11-25 07:26:49 EST
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.
Comment 7 Jeff Layton 2009-06-23 12:36:47 EDT
Closing this bug out since there's little we can do for it.

Note You need to log in before you can comment on or make changes to this bug.