generated from delphix/.github
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configure Mend for GitHub.com #42
Open
mend-for-github-com
wants to merge
1,617
commits into
develop
Choose a base branch
from
whitesource/configure
base: develop
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
BugLink: https://bugs.launchpad.net/bugs/2082641 The return values for cifs_chan_update_iface() didn't match what the documentation said and nothing was checking them anyway. Just make it a void function. Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 8d606c3) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Return statement was not needed at end of cifs_chan_update_iface Suggested-by: Christophe Jaillet <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit a3f763f) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 From 2.46 to 2.47 Signed-off-by: Steve French <[email protected]> (cherry picked from commit 3681fe1b0fee42da3d763fdb0aae62ea032aab86) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 The variable tcon_exist is being assigned however it is never read, the variable is redundant and can be removed. Cleans up clang scan build warning: warning: Although the value stored to 'tcon_exist' is used in the enclosing expression, the value is never actually readfrom 'tcon_exist' [deadcode.DeadStores] Signed-off-by: Colin Ian King <[email protected]> Signed-off-by: Steve French <[email protected] (cherry picked from commit 8ca5d26) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 In analyzing problems, one missing piece of debug data is when the mount occurred. A related problem is when collecting stats we don't know the period of time the stats covered, ie when this set of stats for the tcon started to be collected. To make debugging easier track the stats begin time. Set it when the mount occurred at mount time, and reset it to current time whenever stats are reset. For example, ... 1) \\localhost\test SMBs: 14 since 2024-01-17 22:17:30 UTC Bytes read: 0 Bytes written: 0 Open files: 0 total (local), 0 open on server TreeConnects: 1 total 0 failed TreeDisconnects: 0 total 0 failed ... 2) \\localhost\scratch SMBs: 24 since 2024-01-17 22:16:04 UTC Bytes read: 0 Bytes written: 0 Open files: 0 total (local), 0 open on server TreeConnects: 1 total 0 failed TreeDisconnects: 0 total 0 failed ... Note the time "since ... UTC" is now displayed in /proc/fs/cifs/Stats for each share that is mounted. Suggested-by: Shyam Prasad N <[email protected]> Reviewed-by: Bharath SM <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit d8392c2) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 minor comment cleanup and trivial camelCase removal Reviewed-by: Bharath SM <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 0b549c4) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 open_cached_dir today selects ses->server a.k.a primary channel to send requests. When multichannel is used, the primary channel maybe down. So it does not make sense to rely only on that channel. This fix makes this function pick a channel with the standard helper function cifs_pick_channel. Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 936eba9) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Today, the tree connect and disconnect requests are sent on the primary channel only. However, the new multichannel logic allows the session to remain active even if one of the channels are alive. So a tree connect can now be triggered during a reconnect on any of its channels. This change changes tcon and tdis calls to pick an active channel instead of the first one. Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 268b8b5) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 MS-SMB2 spec has introduced two new status codes, STATUS_SERVER_UNAVAILABLE and STATUS_FILE_NOT_AVAILABLE which are to be treated as retryable errors. This change adds these to the available mappings and maps them to Linux errno EAGAIN. Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 7f73852) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 The data offset for the SMB3.1.1 POSIX create context will always be 8-byte aligned so having the check 'noff + nlen >= doff' in smb2_parse_contexts() is wrong as it will lead to -EINVAL because noff + nlen == doff. Fix the sanity check to correctly handle aligned create context data. Fixes: af1689a ("smb: client: fix potential OOBs in smb2_parse_contexts()") Signed-off-by: Paulo Alcantara <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 76025cc) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Parse owner/group when creating special files and symlinks under SMB3.1.1 POSIX mounts. Move the parsing of owner/group to smb2_compound_op() so we don't have to duplicate it in both smb2_get_reparse_inode() and smb311_posix_query_path_info(). Signed-off-by: Paulo Alcantara <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 858e748) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Merge smb311_posix_query_path_info into ->query_path_info() to get rid of duplicate code. Signed-off-by: Paulo Alcantara <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit f83709b) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Don't clobber ->i_rdev from valid reparse inodes over readdir(2) as it can't be provided by query dir responses. Signed-off-by: Paulo Alcantara <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 66c9314) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Today, we schedule periodic query for server interfaces once every 10 minutes once a tree connection has been established. Recent change to handle disabling of multichannel disabled this delayed work. This change reenables it following a reconnect, and the server advertises multichannel. Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 49fe25c) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 We have several places in the code where we treat the error -EAGAIN very differently. Some code retry for arbitrary number of times. Introducing this new mount option named "retrans", so that all these handlers of -EAGAIN can retry a fixed number of times. This applies only to soft mounts. Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit ce09f8d) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Some servers like Azure SMB servers always advertise multichannel capability in server capabilities list. Such servers return error STATUS_NOT_IMPLEMENTED for ioctl calls to query server interfaces, and expect clients to consider that as a sign that they do not support multichannel. We already handled this at mount time. Soon after the tree connect, we query server interfaces. And when server returned STATUS_NOT_IMPLEMENTED, we kept interface list as empty. When cifs_try_adding_channels gets called, it would not find any interfaces, so will not add channels. For the case where an active multichannel mount exists, and multichannel is disabled by such a server, this change will now allow the client to disable secondary channels on the mount. It will check the return status of query server interfaces call soon after a tree reconnect. If the return status is EOPNOTSUPP, then instead of the check to add more channels, we'll disable the secondary channels instead. For better code reuse, this change also moves the common code for disabling multichannel to a helper function. Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit f591062) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 iface_last_update was an unused field when it was introduced. Later, when we had periodic update of server interface list, this field was used regularly to decide when to update next. However, with the new logic of updating the interfaces, it becomes crucial that this field be updated whenever parse_server_interfaces runs successfully. This change updates this field when either the server does not support query of interfaces; so that we do not query the interfaces repeatedly. It also updates the field when the function reaches the end. Fixes: aa45dad ("cifs: change iface_list from array to sorted linked list") Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 78e727e) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Kernel has its own official true/false definitions. The defines aren't even used in this file. Signed-off-by: Alexey Dobriyan <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 5d390df) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Recent versions of Clang gets confused about the possible size of the "user" allocation, and CONFIG_FORTIFY_SOURCE ends up emitting a warning[1]: repro.c:126:4: warning: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Wattribute-warning] 126 | __write_overflow_field(p_size_field, size); | ^ for this memset(): int len; __le16 *user; ... len = ses->user_name ? strlen(ses->user_name) : 0; user = kmalloc(2 + (len * 2), GFP_KERNEL); ... if (len) { ... } else { memset(user, '\0', 2); } While Clang works on this bug[2], switch to using a direct assignment, which avoids memset() entirely which both simplifies the code and silences the false positive warning. (Making "len" size_t also silences the warning, but the direct assignment seems better.) Reported-by: Nathan Chancellor <[email protected]> Closes: ClangBuiltLinux/linux#1966 [1] Link: llvm/llvm-project#77813 [2] Cc: Steve French <[email protected]> Cc: Paulo Alcantara <[email protected]> Cc: Ronnie Sahlberg <[email protected]> Cc: Shyam Prasad N <[email protected]> Cc: Tom Talpey <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Kees Cook <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 8deb05c) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Currently, when a rename, unlink or set path size compound operation is requested on a file that has a lot of dirty pages to be written to the server, we do not send the lease key for these requests. As a result, the server can assume that this request is from a new client, and send a lease break notification to the same client, on the same connection. As a response to the lease break, the client can consume several credits to write the dirty pages to the server. Depending on the server's credit grant implementation, the server can stop granting more credits to this connection, and this can cause a deadlock (which can only be resolved when the lease timer on the server expires). One of the problems here is that the client is sending no lease key, even if it has a lease for the file. This patch fixes the problem by reusing the existing lease key on the file for rename, unlink and set path size compound operations so that the client does not break its own lease. A very trivial example could be a set of commands by a client that maintains open handle (for write) to a file and then tries to copy the contents of that file to another one, eg., tail -f /dev/null > myfile & mv myfile myfile2 Presently, the network capture on the client shows that the move (or rename) would trigger a lease break on the same client, for the same file. With the lease key reused, the lease break request-response overhead is eliminated, thereby reducing the roundtrips performed for this set of operations. The patch fixes the bug described above and also provides perf benefit. Signed-off-by: Meetakshi Setiya <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 2c7d399e551ccfd87bcae4ef5573097f3313d779) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 When a file/dentry has been deleted before closing all its open handles, currently, closing them can add them to the deferred close list. This can lead to problems in creating file with the same name when the file is re-created before the deferred close completes. This issue was seen while reusing a client's already existing lease on a file for compound operations and xfstest 591 failed because of the deferred close handle that remained valid even after the file was deleted and was being reused to create a file with the same name. The server in this case returns an error on open with STATUS_DELETE_PENDING. Recreating the file would fail till the deferred handles are closed (duration specified in closetimeo). This patch fixes the issue by flagging all open handles for the deleted file (file path to be precise) by setting status_file_deleted to true in the cifsFileInfo structure. As per the information classes specified in MS-FSCC, SMB2 query info response from the server has a DeletePending field, set to true to indicate that deletion has been requested on that file. If this is the case, flag the open handles for this file too. When doing close in cifs_close for each of these handles, check the value of this boolean field and do not defer close these handles if the corresponding filepath has been deleted. Signed-off-by: Meetakshi Setiya <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit ffceb7640cbfe6ea60e7769e107451d63a2fe3d3) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 There is a shortcoming in the current implementation of the file lease mechanism exposed when the lease keys were attempted to be reused for unlink, rename and set_path_size operations for a client. As per MS-SMB2, lease keys are associated with the file name. Linux smb client maintains lease keys with the inode. If the file has any hardlinks, it is possible that the lease for a file be wrongly reused for an operation on the hardlink or vice versa. In these cases, the mentioned compound operations fail with STATUS_INVALID_PARAMETER. This patch adds a fallback to the old mechanism of not sending any lease with these compound operations if the request with lease key fails with STATUS_INVALID_PARAMETER. Resending the same request without lease key should not hurt any functionality, but might impact performance especially in cases where the error is not because of the usage of wrong lease key and we might end up doing an extra roundtrip. Signed-off-by: Meetakshi Setiya <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 71f15c90e785d1de4bcd65a279e7256684c25c0d) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Fix potential memory leaks, add error checking, remove unnecessary initialisation of status_file_deleted and do not use cifs_iget() to get inode in reparse_info_to_fattr since fattrs may not be fully set. Fixes: ffceb7640cbf ("smb: client: do not defer close open handles to deleted files") Reported-by: Paulo Alcantara <[email protected]> Signed-off-by: Meetakshi Setiya <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit fc20c523211a38b87fc850a959cb2149e4fd64b0) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
…_file() BugLink: https://bugs.launchpad.net/bugs/2082641 cifs_get_fattr() may be called with a NULL inode, so check for a non-NULL inode before calling cifs_mark_open_handles_for_deleted_file(). This fixes the following oops: mount.cifs //srv/share /mnt -o ...,vers=3.1.1 cd /mnt touch foo; tail -f foo & rm foo cat foo BUG: kernel NULL pointer dereference, address: 00000000000005c0 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 696 Comm: cat Not tainted 6.9.0-rc2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014 RIP: 0010:__lock_acquire+0x5d/0x1c70 Code: 00 00 44 8b a4 24 a0 00 00 00 45 85 f6 0f 84 bb 06 00 00 8b 2d 48 e2 95 01 45 89 c3 41 89 d2 45 89 c8 85 ed 0 0 <48> 81 3f 40 7a 76 83 44 0f 44 d8 83 fe 01 0f 86 1b 03 00 00 31 d2 RSP: 0018:ffffc90000b37490 EFLAGS: 00010002 RAX: 0000000000000000 RBX: ffff888110021ec0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000000005c0 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000200 FS: 00007f2a1fa08740(0000) GS:ffff888157a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000005c0 CR3: 000000011ac7c000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: <TASK> ? __die+0x23/0x70 ? page_fault_oops+0x180/0x490 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x70/0x230 ? asm_exc_page_fault+0x26/0x30 ? __lock_acquire+0x5d/0x1c70 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 lock_acquire+0xc0/0x2d0 ? cifs_mark_open_handles_for_deleted_file+0x3a/0x100 [cifs] ? srso_alias_return_thunk+0x5/0xfbef5 ? kmem_cache_alloc+0x2d9/0x370 _raw_spin_lock+0x34/0x80 ? cifs_mark_open_handles_for_deleted_file+0x3a/0x100 [cifs] cifs_mark_open_handles_for_deleted_file+0x3a/0x100 [cifs] cifs_get_fattr+0x24c/0x940 [cifs] ? srso_alias_return_thunk+0x5/0xfbef5 cifs_get_inode_info+0x96/0x120 [cifs] cifs_lookup+0x16e/0x800 [cifs] cifs_atomic_open+0xc7/0x5d0 [cifs] ? lookup_open.isra.0+0x3ce/0x5f0 ? __pfx_cifs_atomic_open+0x10/0x10 [cifs] lookup_open.isra.0+0x3ce/0x5f0 path_openat+0x42b/0xc30 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 do_filp_open+0xc4/0x170 do_sys_openat2+0xab/0xe0 __x64_sys_openat+0x57/0xa0 do_syscall_64+0xc1/0x1e0 entry_SYSCALL_64_after_hwframe+0x72/0x7a Fixes: ffceb7640cbf ("smb: client: do not defer close open handles to deleted files") Reviewed-by: Meetakshi Setiya <[email protected]> Reviewed-by: Bharath SM <[email protected]> Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit ec4535b2a1d709d3a1fbec26739c672f13c98a7b) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 If smb2_compound_op() is called with a valid @CFILE and returned -EINVAL, we need to call cifs_get_writable_path() before retrying it as the reference of @CFILE was already dropped by previous call. This fixes the following KASAN splat when running fstests generic/013 against Windows Server 2022: CIFS: Attempting to mount //w22-fs0/scratch run fstests generic/013 at 2024-09-02 19:48:59 ================================================================== BUG: KASAN: slab-use-after-free in detach_if_pending+0xab/0x200 Write of size 8 at addr ffff88811f1a3730 by task kworker/3:2/176 CPU: 3 UID: 0 PID: 176 Comm: kworker/3:2 Not tainted 6.11.0-rc6 #2 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: cifsoplockd cifs_oplock_break [cifs] Call Trace: <TASK> dump_stack_lvl+0x5d/0x80 ? detach_if_pending+0xab/0x200 print_report+0x156/0x4d9 ? detach_if_pending+0xab/0x200 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? detach_if_pending+0xab/0x200 kasan_report+0xda/0x110 ? detach_if_pending+0xab/0x200 detach_if_pending+0xab/0x200 timer_delete+0x96/0xe0 ? __pfx_timer_delete+0x10/0x10 ? rcu_is_watching+0x20/0x50 try_to_grab_pending+0x46/0x3b0 __cancel_work+0x89/0x1b0 ? __pfx___cancel_work+0x10/0x10 ? kasan_save_track+0x14/0x30 cifs_close_deferred_file+0x110/0x2c0 [cifs] ? __pfx_cifs_close_deferred_file+0x10/0x10 [cifs] ? __pfx_down_read+0x10/0x10 cifs_oplock_break+0x4c1/0xa50 [cifs] ? __pfx_cifs_oplock_break+0x10/0x10 [cifs] ? lock_is_held_type+0x85/0xf0 ? mark_held_locks+0x1a/0x90 process_one_work+0x4c6/0x9f0 ? find_held_lock+0x8a/0xa0 ? __pfx_process_one_work+0x10/0x10 ? lock_acquired+0x220/0x550 ? __list_add_valid_or_report+0x37/0x100 worker_thread+0x2e4/0x570 ? __kthread_parkme+0xd1/0xf0 ? __pfx_worker_thread+0x10/0x10 kthread+0x17f/0x1c0 ? kthread+0xda/0x1c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 1118: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 cifs_new_fileinfo+0xc8/0x9d0 [cifs] cifs_atomic_open+0x467/0x770 [cifs] lookup_open.isra.0+0x665/0x8b0 path_openat+0x4c3/0x1380 do_filp_open+0x167/0x270 do_sys_openat2+0x129/0x160 __x64_sys_creat+0xad/0xe0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Freed by task 83: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x70 poison_slab_object+0xe9/0x160 __kasan_slab_free+0x32/0x50 kfree+0xf2/0x300 process_one_work+0x4c6/0x9f0 worker_thread+0x2e4/0x570 kthread+0x17f/0x1c0 ret_from_fork+0x31/0x60 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x30/0x50 __kasan_record_aux_stack+0xad/0xc0 insert_work+0x29/0xe0 __queue_work+0x5ea/0x760 queue_work_on+0x6d/0x90 _cifsFileInfo_put+0x3f6/0x770 [cifs] smb2_compound_op+0x911/0x3940 [cifs] smb2_set_path_size+0x228/0x270 [cifs] cifs_set_file_size+0x197/0x460 [cifs] cifs_setattr+0xd9c/0x14b0 [cifs] notify_change+0x4e3/0x740 do_truncate+0xfa/0x180 vfs_truncate+0x195/0x200 __x64_sys_truncate+0x109/0x150 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Fixes: 71f15c90e785 ("smb: client: retry compound request without reusing lease") Cc: [email protected] Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit f9c169b51b6ce20394594ef674d6b10efba31220) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 If smb2_set_path_attr() is called with a valid @CFILE and returned -EINVAL, we need to call cifs_get_writable_path() again as the reference of @CFILE was already dropped by previous smb2_compound_op() call. Fixes: 71f15c90e785 ("smb: client: retry compound request without reusing lease") Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Cc: David Howells <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 3523a3df03c6f04f7ea9c2e7050102657e331a4f) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 When the server reports query network interface info call as unsupported following a tree connect, it means that multichannel is unsupported, even if the server capabilities report otherwise. When this happens, cifs_chan_skip_or_disable is called to disable multichannel on the client. However, we only need to call this when multichannel is currently setup. Fixes: f591062 ("cifs: handle servers that still advertise multichannel after disabling") Signed-off-by: Shyam Prasad N <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit e77e15f) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
…ork_open_info BugLink: https://bugs.launchpad.net/bugs/2082641 4byte padding cause the connection issue with the applications of MacOS. smb2_close response size increases by 4 bytes by padding, And the smb client of MacOS check it and stop the connection. This patch use struct_group_attr instead of struct_group for network_open_info to use __packed to avoid padding. Fixes: 0015eb6 ("smb: client, common: fix fortify warnings") Cc: [email protected] Signed-off-by: Namjae Jeon <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 0268a7cc7fdc47d90b6c18859de7718d5059f6f1) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 Use struct_group_attr() in __packed structs, instead of struct_group(). Below you can see the pahole output before/after changes: pahole -C smb2_file_network_open_info fs/smb/client/smb2ops.o struct smb2_file_network_open_info { union { struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le64 AllocationSize; /* 32 8 */ __le64 EndOfFile; /* 40 8 */ __le32 Attributes; /* 48 4 */ }; /* 0 56 */ struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le64 AllocationSize; /* 32 8 */ __le64 EndOfFile; /* 40 8 */ __le32 Attributes; /* 48 4 */ } network_open_info; /* 0 56 */ }; /* 0 56 */ __le32 Reserved; /* 56 4 */ /* size: 60, cachelines: 1, members: 2 */ /* last cacheline: 60 bytes */ } __attribute__((__packed__)); pahole -C smb2_file_network_open_info fs/smb/client/smb2ops.o struct smb2_file_network_open_info { union { struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le64 AllocationSize; /* 32 8 */ __le64 EndOfFile; /* 40 8 */ __le32 Attributes; /* 48 4 */ } __attribute__((__packed__)); /* 0 52 */ struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le64 AllocationSize; /* 32 8 */ __le64 EndOfFile; /* 40 8 */ __le32 Attributes; /* 48 4 */ } __attribute__((__packed__)) network_open_info; /* 0 52 */ }; /* 0 52 */ __le32 Reserved; /* 52 4 */ /* size: 56, cachelines: 1, members: 2 */ /* last cacheline: 56 bytes */ }; pahole -C smb_com_open_rsp fs/smb/client/cifssmb.o struct smb_com_open_rsp { ... union { struct { __le64 CreationTime; /* 48 8 */ __le64 LastAccessTime; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ __le64 LastWriteTime; /* 64 8 */ __le64 ChangeTime; /* 72 8 */ __le32 FileAttributes; /* 80 4 */ }; /* 48 40 */ struct { __le64 CreationTime; /* 48 8 */ __le64 LastAccessTime; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ __le64 LastWriteTime; /* 64 8 */ __le64 ChangeTime; /* 72 8 */ __le32 FileAttributes; /* 80 4 */ } common_attributes; /* 48 40 */ }; /* 48 40 */ ... /* size: 111, cachelines: 2, members: 14 */ /* last cacheline: 47 bytes */ } __attribute__((__packed__)); pahole -C smb_com_open_rsp fs/smb/client/cifssmb.o struct smb_com_open_rsp { ... union { struct { __le64 CreationTime; /* 48 8 */ __le64 LastAccessTime; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ __le64 LastWriteTime; /* 64 8 */ __le64 ChangeTime; /* 72 8 */ __le32 FileAttributes; /* 80 4 */ } __attribute__((__packed__)); /* 48 36 */ struct { __le64 CreationTime; /* 48 8 */ __le64 LastAccessTime; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */ __le64 LastWriteTime; /* 64 8 */ __le64 ChangeTime; /* 72 8 */ __le32 FileAttributes; /* 80 4 */ } __attribute__((__packed__)) common_attributes; /* 48 36 */ }; /* 48 36 */ ... /* size: 107, cachelines: 2, members: 14 */ /* last cacheline: 43 bytes */ } __attribute__((__packed__)); pahole -C FILE_ALL_INFO fs/smb/client/cifssmb.o typedef struct { union { struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le32 Attributes; /* 32 4 */ }; /* 0 40 */ struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le32 Attributes; /* 32 4 */ } common_attributes; /* 0 40 */ }; /* 0 40 */ ... /* size: 113, cachelines: 2, members: 17 */ /* last cacheline: 49 bytes */ } __attribute__((__packed__)) FILE_ALL_INFO; pahole -C FILE_ALL_INFO fs/smb/client/cifssmb.o typedef struct { union { struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le32 Attributes; /* 32 4 */ } __attribute__((__packed__)); /* 0 36 */ struct { __le64 CreationTime; /* 0 8 */ __le64 LastAccessTime; /* 8 8 */ __le64 LastWriteTime; /* 16 8 */ __le64 ChangeTime; /* 24 8 */ __le32 Attributes; /* 32 4 */ } __attribute__((__packed__)) common_attributes; /* 0 36 */ }; /* 0 36 */ ... /* size: 109, cachelines: 2, members: 17 */ /* last cacheline: 45 bytes */ } __attribute__((__packed__)) FILE_ALL_INFO; Fixes: 0015eb6 ("smb: client, common: fix fortify warnings") Cc: [email protected] Reviewed-by: Namjae Jeon <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 9a1f1d04f63c59550a5364858b46eeffdf03e8d6) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082641 As per MS-FSA 2.1.5.10.14, support for FSCTL_GET_REPARSE_POINT is optional and if the server doesn't support it, STATUS_INVALID_DEVICE_REQUEST must be returned for the operation. If we find files with reparse points and we can't read them due to lack of client or server support, just ignore it and then treat them as regular files or junctions. Fixes: 5f71ebc ("smb: client: parse reparse point flag in create response") Reported-by: Sebastian Steinbeisser <[email protected]> Tested-by: Sebastian Steinbeisser <[email protected]> Acked-by: Tom Talpey <[email protected]> Signed-off-by: Paulo Alcantara (Red Hat) <[email protected]> Signed-off-by: Steve French <[email protected]> (cherry picked from commit 4b96024ef2296b1d323af327cae5e52809b61420) Signed-off-by: John Cabaj <[email protected]> Acked-by: Magali Lemes <[email protected]> Acked-by: Guoqing Jiang <[email protected]> Signed-off-by: John Cabaj <[email protected]>
Ignore: yes Signed-off-by: Roxana Nicolescu <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2078108 Properties: no-test-build Signed-off-by: Roxana Nicolescu <[email protected]>
Signed-off-by: Roxana Nicolescu <[email protected]>
Ignore: yes Signed-off-by: Vinicius Peixoto <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082128 Properties: no-test-build Signed-off-by: Vinicius Peixoto <[email protected]>
Signed-off-by: Vinicius Peixoto <[email protected]>
Ignore: yes Signed-off-by: Vinicius Peixoto <[email protected]>
BugLink: https://bugs.launchpad.net/bugs/2082956 Properties: no-test-build Signed-off-by: Vinicius Peixoto <[email protected]>
Signed-off-by: Vinicius Peixoto <[email protected]>
This is a placeholder commit to separate the Ubuntu kernel source and our patches. Used by kernel_merge_with_upstream() in the linux-pkg repo.
Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Bogdanov <[email protected]> Signed-off-by: Mike Christie <[email protected]> Signed-off-by: Martin K. Petersen <[email protected]> Co-authored-by: Dmitry Bogdanov <[email protected]>
04cc021
to
0087fce
Compare
0087fce
to
9ddadb7
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Welcome to Mend for GitHub.com (formerly WhiteSource). This is an onboarding PR to help you understand and configure settings before Mend starts scanning your repository for security vulnerabilities.
🚦 Mend for GitHub.com will start scanning your repository only once you merge this Pull Request. To disable Mend for GitHub.com, simply close this Pull Request.
What to Expect
This PR contains a '.whitesource' configuration file which can be customized to your needs. If no changes were applied to this file, Mend for GitHub.com will use the default configuration.
Before merging this PR, Make sure the Issues tab is enabled. Once you merge this PR, Mend for GitHub.com will scan your repository and create a GitHub Issue for every vulnerability detected in your repository.
If you do not want a GitHub Issue to be created for each detected vulnerability, you can edit the '.whitesource' file and set the 'minSeverityLevel' parameter to 'NONE'.
If Mend Remediate Workflow Rules are set on your repository (from the Mend 'Integrate' tab), Mend will also generate a fix Pull Request for relevant vulnerabilities.
❓ Got questions? Check out Mend for GitHub.com docs.
If you need any further assistance then you can also request help here.