wireguard-linux/fs/cifs/file.c, branch jd/unified-crypt-queue

smb3: enable swap on SMB3 mounts

2020-04-10T18:32:32Z

Add experimental support for allowing a swap file to be on an SMB3 mount. There are use cases where swapping over a secure network filesystem is preferable. In some cases there are no local block devices large enough, and network block devices can be hard to setup and secure. And in some cases there are no local block devices at all (e.g. with the recent addition of remote boot over SMB3 mounts). There are various enhancements that can be added later e.g.: - doing a mandatory byte range lock over the swapfile (until the Linux VFS is modified to notify the file system that an open is for a swapfile, when the file can be opened "DENY_ALL" to prevent others from opening it). - pinning more buffers in the underlying transport to minimize memory allocations in the TCP stack under the fs - documenting how to create ACLs (on the server) to secure the swapfile (or adding additional tools to cifs-utils to make it easier) Signed-off-by: Steve French Acked-by: Pavel Shilovsky Reviewed-by: Ronnie Sahlberg

CIFS: Fix bug which the return value by asynchronous read is error

2020-03-23T03:49:10Z

This patch is used to fix the bug in collect_uncached_read_data() that rc is automatically converted from a signed number to an unsigned number when the CIFS asynchronous read fails. It will cause ctx->rc is error. Example: Share a directory and create a file on the Windows OS. Mount the directory to the Linux OS using CIFS. On the CIFS client of the Linux OS, invoke the pread interface to deliver the read request. The size of the read length plus offset of the read request is greater than the maximum file size. In this case, the CIFS server on the Windows OS returns a failure message (for example, the return value of smb2.nt_status is STATUS_INVALID_PARAMETER). After receiving the response message, the CIFS client parses smb2.nt_status to STATUS_INVALID_PARAMETER and converts it to the Linux error code (rdata->result=-22). Then the CIFS client invokes the collect_uncached_read_data function to assign the value of rdata->result to rc, that is, rc=rdata->result=-22. The type of the ctx->total_len variable is unsigned integer, the type of the rc variable is integer, and the type of the ctx->rc variable is ssize_t. Therefore, during the ternary operation, the value of rc is automatically converted to an unsigned number. The final result is ctx->rc=4294967274. However, the expected result is ctx->rc=-22. Signed-off-by: Yilu Lin Signed-off-by: Steve French CC: Stable Acked-by: Ronnie Sahlberg

locks: reinstate locks_delete_block optimization

2020-03-18T20:03:38Z

There is measurable performance impact in some synthetic tests due to commit 6d390e4b5d48 (locks: fix a potential use-after-free problem when wakeup a waiter). Fix the race condition instead by clearing the fl_blocker pointer after the wake_up, using explicit acquire/release semantics. This does mean that we can no longer use the clearing of fl_blocker as the wait condition, so switch the waiters over to checking whether the fl_blocked_member list_head is empty. Reviewed-by: yangerkun Reviewed-by: NeilBrown Fixes: 6d390e4b5d48 (locks: fix a potential use-after-free problem when wakeup a waiter) Signed-off-by: Jeff Layton Signed-off-by: Linus Torvalds

cifs: fix rename() by ensuring source handle opened with DELETE bit

2020-02-24T20:20:38Z

To rename a file in SMB2 we open it with the DELETE access and do a special SetInfo on it. If the handle is missing the DELETE bit the server will fail the SetInfo with STATUS_ACCESS_DENIED. We currently try to reuse any existing opened handle we have with cifs_get_writable_path(). That function looks for handles with WRITE access but doesn't check for DELETE, making rename() fail if it finds a handle to reuse. Simple reproducer below. To select handles with the DELETE bit, this patch adds a flag argument to cifs_get_writable_path() and find_writable_file() and the existing 'bool fsuid_only' argument is converted to a flag. The cifsFileInfo struct only stores the UNIX open mode but not the original SMB access flags. Since the DELETE bit is not mapped in that mode, this patch stores the access mask in cifs_fid on file open, which is accessible from cifsFileInfo. Simple reproducer: #include #include #include #include #include #include #define E(s) perror(s), exit(1) int main(int argc, char *argv[]) { int fd, ret; if (argc != 3) { fprintf(stderr, "Usage: %s A B\n" "create&open A in write mode, " "rename A to B, close A\n", argv[0]); return 0; } fd = openat(AT_FDCWD, argv[1], O_WRONLY|O_CREAT|O_SYNC, 0666); if (fd == -1) E("openat()"); ret = rename(argv[1], argv[2]); if (ret) E("rename()"); ret = close(fd); if (ret) E("close()"); return ret; } $ gcc -o bugrename bugrename.c $ ./bugrename /mnt/a /mnt/b rename(): Permission denied Fixes: 8de9e86c67ba ("cifs: create a helper to find a writeable handle by path name") CC: Stable Signed-off-by: Aurelien Aptel Signed-off-by: Steve French Reviewed-by: Pavel Shilovsky Reviewed-by: Paulo Alcantara (SUSE)

smb3: add one more dynamic tracepoint missing from strict fsync path

2020-02-06T23:21:23Z

We didn't have a dynamic trace point for catching errors in file_write_and_wait_range error cases in cifs_strict_fsync. Since not all apps check for write behind errors, it can be important for debugging to be able to trace these error paths. Suggested-and-reviewed-by: Pavel Shilovsky Signed-off-by: Steve French

cifs: Add tracepoints for errors on flush or fsync

2020-02-06T00:24:19Z

Makes it easier to debug errors on writeback that happen later, and are being returned on flush or fsync For example: writetest-17829 [002] .... 13583.407859: cifs_flush_err: ino=90 rc=-28 Signed-off-by: Steve French

SMB3: Backup intent flag missing from some more ops

2020-02-03T22:12:47Z

When "backup intent" is requested on the mount (e.g. backupuid or backupgid mount options), the corresponding flag was missing from some of the operations. Change all operations to use the macro cifs_create_options() to set the backup intent flag if needed. Signed-off-by: Amir Goldstein Signed-off-by: Steve French

cifs: Don't use iov_iter::type directly

2020-01-27T01:24:16Z

Don't use iov_iter::type directly, but rather use the new accessor functions that have been added. This allows the .type field to be split and rearranged without the need to update the filesystems. Signed-off-by: David Howells Signed-off-by: Steve French

smb3: query attributes on file close

2019-12-03T21:48:02Z

Since timestamps on files on most servers can be updated at close, and since timestamps on our dentries default to one second we can have stale timestamps in some common cases (e.g. open, write, close, stat, wait one second, stat - will show different mtime for the first and second stat). The SMB2/SMB3 protocol allows querying timestamps at close so add the code to request timestamp and attr information (which is cheap for the server to provide) to be returned when a file is closed (it is not needed for the many paths that call SMB2_close that are from compounded query infos and close nor is it needed for some of the cases where a directory close immediately follows a directory open. Signed-off-by: Steve French Acked-by: Ronnie Sahlberg Reviewed-by: Aurelien Aptel Reviewed-by: Pavel Shilovsky

CIFS: Fix NULL-pointer dereference in smb2_push_mandatory_locks

2019-12-02T21:15:00Z

Currently when the client creates a cifsFileInfo structure for a newly opened file, it allocates a list of byte-range locks with a pointer to the new cfile and attaches this list to the inode's lock list. The latter happens before initializing all other fields, e.g. cfile->tlink. Thus a partially initialized cifsFileInfo structure becomes available to other threads that walk through the inode's lock list. One example of such a thread may be an oplock break worker thread that tries to push all cached byte-range locks. This causes NULL-pointer dereference in smb2_push_mandatory_locks() when accessing cfile->tlink: [598428.945633] BUG: kernel NULL pointer dereference, address: 0000000000000038 ... [598428.945749] Workqueue: cifsoplockd cifs_oplock_break [cifs] [598428.945793] RIP: 0010:smb2_push_mandatory_locks+0xd6/0x5a0 [cifs] ... [598428.945834] Call Trace: [598428.945870] ? cifs_revalidate_mapping+0x45/0x90 [cifs] [598428.945901] cifs_oplock_break+0x13d/0x450 [cifs] [598428.945909] process_one_work+0x1db/0x380 [598428.945914] worker_thread+0x4d/0x400 [598428.945921] kthread+0x104/0x140 [598428.945925] ? process_one_work+0x380/0x380 [598428.945931] ? kthread_park+0x80/0x80 [598428.945937] ret_from_fork+0x35/0x40 Fix this by reordering initialization steps of the cifsFileInfo structure: initialize all the fields first and then add the new byte-range lock list to the inode's lock list. Cc: Stable Signed-off-by: Pavel Shilovsky Reviewed-by: Aurelien Aptel Signed-off-by: Steve French