[PATCH] cifs: Close deferred files that may be open via hard links

[Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>]

Windows Server (tested with 2016) disallows opening the same inode via
two different hardlinks at the same time. With deferred closes, this can
result in unexpected behaviour as the following Python snippet shows:

    # Create file
    fd = os.open('test', os.O_WRONLY|os.O_CREAT)
    os.write(fd, b'foo')
    os.close(fd)

    # Open and close the file to leave a pending deferred close
    fd = os.open('test', os.O_RDONLY|os.O_DIRECT)
    os.close(fd)

    # Try to open the file via a hard link
    os.link('test', 'new')
    newfd = os.open('new', os.O_RDONLY|os.O_DIRECT)

The final open returns EINVAL due to the server returning
STATUS_INVALID_PARAMETER.

Fix this by closing any deferred closes that may be open via other hard
links if we haven't successfully reused a cached handle.

Fixes: c3f207ab29f7 ("cifs: Deferred close for files")
Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
---

This is kind of an RFC. Is the server doing the wrong thing? Is it
correct to work around this in the client?

 fs/cifs/file.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index c5fcefdfd797..723cbc060f57 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -749,6 +749,7 @@ int cifs_open(struct inode *inode, struct file *file)
 			_cifsFileInfo_put(cfile, true, false);
 		}
 	}
+	cifs_close_deferred_file(CIFS_I(inode));
 
 	if (server->oplocks)
 		oplock = REQ_OPLOCK;
-- 
2.31.1