From 83f161eb6997624f2d25a54994a3cdf1e7b8b5c1 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Mon, 10 May 2021 09:56:52 +0200 Subject: [PATCH] 5.12-stable patches added patches: futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch --- ...amespace-adjustment-on-futex_lock_pi.patch | 47 +++++++++++++++++++ ...ex_clock_realtime-with-futex_wait-op.patch | 46 ++++++++++++++++++ queue-5.12/series | 6 +++ ...-to-server-which-does-not-support-it.patch | 38 +++++++++++++++ ...han-one-channel-request-multichannel.patch | 36 ++++++++++++++ ...include-it-in-requested-capabilities.patch | 47 +++++++++++++++++++ ..._aux-if-rdtscp-or-rdpid-is-supported.patch | 43 +++++++++++++++++ 7 files changed, 263 insertions(+) create mode 100644 queue-5.12/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch create mode 100644 queue-5.12/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch create mode 100644 queue-5.12/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch create mode 100644 queue-5.12/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch create mode 100644 queue-5.12/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch create mode 100644 queue-5.12/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch diff --git a/queue-5.12/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch b/queue-5.12/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch new file mode 100644 index 00000000000..043d71b5c2f --- /dev/null +++ b/queue-5.12/futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch @@ -0,0 +1,47 @@ +From cdf78db4070967869e4d027c11f4dd825d8f815a Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 22 Apr 2021 21:44:19 +0200 +Subject: futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI + +From: Thomas Gleixner + +commit cdf78db4070967869e4d027c11f4dd825d8f815a upstream. + +FUTEX_LOCK_PI does not require to have the FUTEX_CLOCK_REALTIME bit set +because it has been using CLOCK_REALTIME based absolute timeouts +forever. Due to that, the time namespace adjustment which is applied when +FUTEX_CLOCK_REALTIME is not set, will wrongly take place for FUTEX_LOCK_PI +and wreckage the timeout. + +Exclude it from that procedure. + +Fixes: c2f7d08cccf4 ("futex: Adjust absolute futex timeouts with per time namespace offset") +Signed-off-by: Thomas Gleixner +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210422194704.984540159@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/futex.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -3781,7 +3781,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uad + t = timespec64_to_ktime(ts); + if (cmd == FUTEX_WAIT) + t = ktime_add_safe(ktime_get(), t); +- else if (!(op & FUTEX_CLOCK_REALTIME)) ++ else if (cmd != FUTEX_LOCK_PI && !(op & FUTEX_CLOCK_REALTIME)) + t = timens_ktime_to_host(CLOCK_MONOTONIC, t); + tp = &t; + } +@@ -3975,7 +3975,7 @@ SYSCALL_DEFINE6(futex_time32, u32 __user + t = timespec64_to_ktime(ts); + if (cmd == FUTEX_WAIT) + t = ktime_add_safe(ktime_get(), t); +- else if (!(op & FUTEX_CLOCK_REALTIME)) ++ else if (cmd != FUTEX_LOCK_PI && !(op & FUTEX_CLOCK_REALTIME)) + t = timens_ktime_to_host(CLOCK_MONOTONIC, t); + tp = &t; + } diff --git a/queue-5.12/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch b/queue-5.12/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch new file mode 100644 index 00000000000..b78f42be4fb --- /dev/null +++ b/queue-5.12/revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch @@ -0,0 +1,46 @@ +From 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Thu, 22 Apr 2021 21:44:18 +0200 +Subject: Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") + +From: Thomas Gleixner + +commit 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 upstream. + +The FUTEX_WAIT operand has historically a relative timeout which means that +the clock id is irrelevant as relative timeouts on CLOCK_REALTIME are not +subject to wall clock changes and therefore are mapped by the kernel to +CLOCK_MONOTONIC for simplicity. + +If a caller would set FUTEX_CLOCK_REALTIME for FUTEX_WAIT the timeout is +still treated relative vs. CLOCK_MONOTONIC and then the wait arms that +timeout based on CLOCK_REALTIME which is broken and obviously has never +been used or even tested. + +Reject any attempt to use FUTEX_CLOCK_REALTIME with FUTEX_WAIT again. + +The desired functionality can be achieved with FUTEX_WAIT_BITSET and a +FUTEX_BITSET_MATCH_ANY argument. + +Fixes: 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op") +Signed-off-by: Thomas Gleixner +Acked-by: Peter Zijlstra (Intel) +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210422194704.834797921@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + kernel/futex.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -3711,8 +3711,7 @@ long do_futex(u32 __user *uaddr, int op, + + if (op & FUTEX_CLOCK_REALTIME) { + flags |= FLAGS_CLOCKRT; +- if (cmd != FUTEX_WAIT && cmd != FUTEX_WAIT_BITSET && \ +- cmd != FUTEX_WAIT_REQUEUE_PI) ++ if (cmd != FUTEX_WAIT_BITSET && cmd != FUTEX_WAIT_REQUEUE_PI) + return -ENOSYS; + } + diff --git a/queue-5.12/series b/queue-5.12/series index 620a1a52d59..170674f4e27 100644 --- a/queue-5.12/series +++ b/queue-5.12/series @@ -328,3 +328,9 @@ sfc-adjust-efx-xdp_tx_queue_count-with-the-real-number-of-initialized-queues.pat rcu-nocb-fix-missed-nocb_timer-requeue.patch security-commoncap-fix-wstringop-overread-warning.patch fix-misc-new-gcc-warnings.patch +smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch +smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch +smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch +revert-337f13046ff0-futex-allow-futex_clock_realtime-with-futex_wait-op.patch +futex-do-not-apply-time-namespace-adjustment-on-futex_lock_pi.patch +x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch diff --git a/queue-5.12/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch b/queue-5.12/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch new file mode 100644 index 00000000000..af53cff55ca --- /dev/null +++ b/queue-5.12/smb3-do-not-attempt-multichannel-to-server-which-does-not-support-it.patch @@ -0,0 +1,38 @@ +From 9c2dc11df50d1c8537075ff6b98472198e24438e Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Fri, 7 May 2021 20:00:41 -0500 +Subject: smb3: do not attempt multichannel to server which does not support it + +From: Steve French + +commit 9c2dc11df50d1c8537075ff6b98472198e24438e upstream. + +We were ignoring CAP_MULTI_CHANNEL in the server response - if the +server doesn't support multichannel we should not be attempting it. + +See MS-SMB2 section 3.2.5.2 + +Reviewed-by: Shyam Prasad N +Reviewed-By: Tom Talpey +Cc: # v5.8+ +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/sess.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +--- a/fs/cifs/sess.c ++++ b/fs/cifs/sess.c +@@ -97,6 +97,12 @@ int cifs_try_adding_channels(struct cifs + return 0; + } + ++ if (!(ses->server->capabilities & SMB2_GLOBAL_CAP_MULTI_CHANNEL)) { ++ cifs_dbg(VFS, "server %s does not support multichannel\n", ses->server->hostname); ++ ses->chan_max = 1; ++ return 0; ++ } ++ + /* + * Make a copy of the iface list at the time and use that + * instead so as to not hold the iface spinlock for opening diff --git a/queue-5.12/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch b/queue-5.12/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch new file mode 100644 index 00000000000..5917141d764 --- /dev/null +++ b/queue-5.12/smb3-if-max_channels-set-to-more-than-one-channel-request-multichannel.patch @@ -0,0 +1,36 @@ +From c1f8a398b6d661b594556a91224b096d92293061 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Fri, 7 May 2021 19:33:51 -0500 +Subject: smb3: if max_channels set to more than one channel request multichannel + +From: Steve French + +commit c1f8a398b6d661b594556a91224b096d92293061 upstream. + +Mounting with "multichannel" is obviously implied if user requested +more than one channel on mount (ie mount parm max_channels>1). +Currently both have to be specified. Fix that so that if max_channels +is greater than 1 on mount, enable multichannel rather than silently +falling back to non-multichannel. + +Signed-off-by: Steve French +Reviewed-By: Tom Talpey +Cc: # v5.11+ +Reviewed-by: Shyam Prasad N +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/fs_context.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/cifs/fs_context.c ++++ b/fs/cifs/fs_context.c +@@ -999,6 +999,9 @@ static int smb3_fs_context_parse_param(s + goto cifs_parse_mount_err; + } + ctx->max_channels = result.uint_32; ++ /* If more than one channel requested ... they want multichan */ ++ if (result.uint_32 > 1) ++ ctx->multichannel = true; + break; + case Opt_handletimeout: + ctx->handle_timeout = result.uint_32; diff --git a/queue-5.12/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch b/queue-5.12/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch new file mode 100644 index 00000000000..69f8d216437 --- /dev/null +++ b/queue-5.12/smb3-when-mounting-with-multichannel-include-it-in-requested-capabilities.patch @@ -0,0 +1,47 @@ +From 679971e7213174efb56abc8fab1299d0a88db0e8 Mon Sep 17 00:00:00 2001 +From: Steve French +Date: Fri, 7 May 2021 18:24:11 -0500 +Subject: smb3: when mounting with multichannel include it in requested capabilities + +From: Steve French + +commit 679971e7213174efb56abc8fab1299d0a88db0e8 upstream. + +In the SMB3/SMB3.1.1 negotiate protocol request, we are supposed to +advertise CAP_MULTICHANNEL capability when establishing multiple +channels has been requested by the user doing the mount. See MS-SMB2 +sections 2.2.3 and 3.2.5.2 + +Without setting it there is some risk that multichannel could fail +if the server interpreted the field strictly. + +Reviewed-By: Tom Talpey +Reviewed-by: Shyam Prasad N +Cc: # v5.8+ +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/cifs/smb2pdu.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/fs/cifs/smb2pdu.c ++++ b/fs/cifs/smb2pdu.c +@@ -841,6 +841,8 @@ SMB2_negotiate(const unsigned int xid, s + req->SecurityMode = 0; + + req->Capabilities = cpu_to_le32(server->vals->req_capabilities); ++ if (ses->chan_max > 1) ++ req->Capabilities |= cpu_to_le32(SMB2_GLOBAL_CAP_MULTI_CHANNEL); + + /* ClientGUID must be zero for SMB2.02 dialect */ + if (server->vals->protocol_id == SMB20_PROT_ID) +@@ -1032,6 +1034,9 @@ int smb3_validate_negotiate(const unsign + + pneg_inbuf->Capabilities = + cpu_to_le32(server->vals->req_capabilities); ++ if (tcon->ses->chan_max > 1) ++ pneg_inbuf->Capabilities |= cpu_to_le32(SMB2_GLOBAL_CAP_MULTI_CHANNEL); ++ + memcpy(pneg_inbuf->Guid, server->client_guid, + SMB2_CLIENT_GUID_SIZE); + diff --git a/queue-5.12/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch b/queue-5.12/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch new file mode 100644 index 00000000000..19881bbac4a --- /dev/null +++ b/queue-5.12/x86-cpu-initialize-msr_tsc_aux-if-rdtscp-or-rdpid-is-supported.patch @@ -0,0 +1,43 @@ +From b6b4fbd90b155a0025223df2c137af8a701d53b3 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Tue, 4 May 2021 15:56:31 -0700 +Subject: x86/cpu: Initialize MSR_TSC_AUX if RDTSCP *or* RDPID is supported + +From: Sean Christopherson + +commit b6b4fbd90b155a0025223df2c137af8a701d53b3 upstream. + +Initialize MSR_TSC_AUX with CPU node information if RDTSCP or RDPID is +supported. This fixes a bug where vdso_read_cpunode() will read garbage +via RDPID if RDPID is supported but RDTSCP is not. While no known CPU +supports RDPID but not RDTSCP, both Intel's SDM and AMD's APM allow for +RDPID to exist without RDTSCP, e.g. it's technically a legal CPU model +for a virtual machine. + +Note, technically MSR_TSC_AUX could be initialized if and only if RDPID +is supported since RDTSCP is currently not used to retrieve the CPU node. +But, the cost of the superfluous WRMSR is negigible, whereas leaving +MSR_TSC_AUX uninitialized is just asking for future breakage if someone +decides to utilize RDTSCP. + +Fixes: a582c540ac1b ("x86/vdso: Use RDPID in preference to LSL when available") +Signed-off-by: Sean Christopherson +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20210504225632.1532621-2-seanjc@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/common.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/common.c ++++ b/arch/x86/kernel/cpu/common.c +@@ -1850,7 +1850,7 @@ static inline void setup_getcpu(int cpu) + unsigned long cpudata = vdso_encode_cpunode(cpu, early_cpu_to_node(cpu)); + struct desc_struct d = { }; + +- if (boot_cpu_has(X86_FEATURE_RDTSCP)) ++ if (boot_cpu_has(X86_FEATURE_RDTSCP) || boot_cpu_has(X86_FEATURE_RDPID)) + write_rdtscp_aux(cpudata); + + /* Store CPU and node number in limit. */ -- 2.47.3