I've been investigating a strange bug that appears to return an
`-EINVAL` when our application attempts to open a newly-renamed file
on a CIFS mount. The good news is that the bug is gone in Linux 5.13
but present in versions preceding that. After doing some git
bisecting, I've validated that commit c3f207ab29f79 (cifs: Deferred
close for files) appears to have solved the problem.
Now I'm wondering: is this bug really fixed, or is this commit masking
another issue?
The `mount` output for this CIFS mount is as follows:
//10.128.0.36/share on /mnt/windows type cifs
(rw,relatime,vers=3.1.1,cache=strict,username=stan,uid=997,noforceuid,gid=997,noforcegid,addr=10.128.0.36,file_mode=0700,dir_mode=0700,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1)
As far as I understand, our application works something like this:
1. Process A writes a small file to a temporary location:
`/mnt/windows/artifacts/tmp/uploads/gitlab-workhorse-upload749963764`
2. Process B calls:
`rename("/mnt/windows/artifacts/tmp/uploads/gitlab-workhorse-upload749963764",
"/mnt/windows/artifacts/tmp/work/1675526501-1286-0001-0710/.env.gz")`
3. Process B calls:
`rename("/mnt/windows/artifacts/tmp/work/1675526501-1286-0001-0710/.env.gz",
"/mnt/windows/artifacts/tmp/cache/1675526501-1286-0001-0710/.env.gz")`.
4. Process B calls: `openat(AT_FDCWD,
"/mnt/windows/artifacts/tmp/cache/1675526501-1286-0001-0710/.env.gz",
O_RDONLY|O_CLOEXEC)`.
An `strace` on our application shows the error:
1108 openat(AT_FDCWD,
"/mnt/windows/artifacts/tmp/cache/1675526501-1286-0001-0710/.env.gz",
O_RDONLY|O_CLOEXEC) = -1 EINVAL (Invalid argument)
However, I can open and read this file fine from the shell.
When I turn on CIFS debugging, I see "STATUS_INVALID_PARAMETER" in
response to cifs_open():
[ 5241.432481] fs/cifs/inode.c: CIFS VFS: leaving cifs_rmdir (xid = 703) rc = 0
[ 5241.436049] fs/cifs/file.c: CIFS VFS: in cifs_open as Xid: 704 with uid: 997
[ 5241.436052] fs/cifs/file.c: inode = 0x00000000028100cc file flags
are 0x8000 for \tmp\cache\1675526501-1286-0001-0710\.env.gz
[ 5241.436588] Status code returned 0xc000000d STATUS_INVALID_PARAMETER
[ 5241.443409] fs/cifs/file.c: CIFS VFS: leaving cifs_open (xid = 704) rc = -22
[ 5241.452108] fs/cifs/file.c: Flush inode 00000000028100cc file
0000000005911244 rc 0
[ 5241.452112] fs/cifs/file.c: closing last open instance for inode
00000000028100cc
[ 5241.452114] fs/cifs/file.c: CIFS VFS: in _cifsFileInfo_put as Xid:
705 with uid: 997
I took a Wireshark pcap of the STATUS_INVALID_PARAMETER response for
another failed run here:
https://gitlab.com/gitlab-org/gitlab/uploads/b047728a695adc098a6d3ce77df2ae7d/test.pcap
Working case: https://gitlab.com/gitlab-org/gitlab/uploads/4df1625bf3ab3775bc97d8b56546eacc/test-working.pcap
In the working case, I see "No oplock" on the "Create request" for the
temporary file in question, and the ExtraInfo flags are a little
different (https://gitlab.com/gitlab-org/gitlab/-/issues/389995#note_1265800095).
I attempted to set "cache=none,actimeo=0" in the mount options, but
that did not seem to help.
