--- /dev/null
+From cdf78db4070967869e4d027c11f4dd825d8f815a Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 22 Apr 2021 21:44:19 +0200
+Subject: futex: Do not apply time namespace adjustment on FUTEX_LOCK_PI
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <tglx@linutronix.de>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210422194704.984540159@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From 4fbf5d6837bf81fd7a27d771358f4ee6c4f243f8 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Thu, 22 Apr 2021 21:44:18 +0200
+Subject: Revert 337f13046ff0 ("futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op")
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+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 <tglx@linutronix.de>
+Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210422194704.834797921@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
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
--- /dev/null
+From 9c2dc11df50d1c8537075ff6b98472198e24438e Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+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 <stfrench@microsoft.com>
+
+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 <sprasad@microsoft.com>
+Reviewed-By: Tom Talpey <tom@talpey.com>
+Cc: <stable@vger.kernel.org> # v5.8+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
--- /dev/null
+From c1f8a398b6d661b594556a91224b096d92293061 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+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 <stfrench@microsoft.com>
+
+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 <stfrench@microsoft.com>
+Reviewed-By: Tom Talpey <tom@talpey.com>
+Cc: <stable@vger.kernel.org> # v5.11+
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
--- /dev/null
+From 679971e7213174efb56abc8fab1299d0a88db0e8 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Fri, 7 May 2021 18:24:11 -0500
+Subject: smb3: when mounting with multichannel include it in requested capabilities
+
+From: Steve French <stfrench@microsoft.com>
+
+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 <tom@talpey.com>
+Reviewed-by: Shyam Prasad N <sprasad@microsoft.com>
+Cc: <stable@vger.kernel.org> # v5.8+
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From b6b4fbd90b155a0025223df2c137af8a701d53b3 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+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 <seanjc@google.com>
+
+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 <seanjc@google.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20210504225632.1532621-2-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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. */
projects / thirdparty / kernel / stable-queue.git / commitdiff
