--- /dev/null
+From 3220022038b9a3845eea762af85f1c5694b9f861 Mon Sep 17 00:00:00 2001
+From: Nick Desaulniers <ndesaulniers@google.com>
+Date: Tue, 11 Oct 2022 20:00:12 +0100
+Subject: ARM: 9256/1: NWFPE: avoid compiler-generated __aeabi_uldivmod
+
+From: Nick Desaulniers <ndesaulniers@google.com>
+
+commit 3220022038b9a3845eea762af85f1c5694b9f861 upstream.
+
+clang-15's ability to elide loops completely became more aggressive when
+it can deduce how a variable is being updated in a loop. Counting down
+one variable by an increment of another can be replaced by a modulo
+operation.
+
+For 64b variables on 32b ARM EABI targets, this can result in the
+compiler generating calls to __aeabi_uldivmod, which it does for a do
+while loop in float64_rem().
+
+For the kernel, we'd generally prefer that developers not open code 64b
+division via binary / operators and instead use the more explicit
+helpers from div64.h. On arm-linux-gnuabi targets, failure to do so can
+result in linkage failures due to undefined references to
+__aeabi_uldivmod().
+
+While developers can avoid open coding divisions on 64b variables, the
+compiler doesn't know that the Linux kernel has a partial implementation
+of a compiler runtime (--rtlib) to enforce this convention.
+
+It's also undecidable for the compiler whether the code in question
+would be faster to execute the loop vs elide it and do the 64b division.
+
+While I actively avoid using the internal -mllvm command line flags, I
+think we get better code than using barrier() here, which will force
+reloads+spills in the loop for all toolchains.
+
+Link: https://github.com/ClangBuiltLinux/linux/issues/1666
+
+Reported-by: Nathan Chancellor <nathan@kernel.org>
+Reviewed-by: Arnd Bergmann <arnd@arndb.de>
+Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
+Tested-by: Nathan Chancellor <nathan@kernel.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm/nwfpe/Makefile | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/arch/arm/nwfpe/Makefile
++++ b/arch/arm/nwfpe/Makefile
+@@ -11,3 +11,9 @@ nwfpe-y += fpa11.o fpa11_cpdo.o fpa11
+ entry.o
+
+ nwfpe-$(CONFIG_FPE_NWFPE_XP) += extended_cpdo.o
++
++# Try really hard to avoid generating calls to __aeabi_uldivmod() from
++# float64_rem() due to loop elision.
++ifdef CONFIG_CC_IS_CLANG
++CFLAGS_softfloat.o += -mllvm -replexitval=never
++endif
--- /dev/null
+From 015d02f48537cf2d1a65eeac50717566f9db6eec Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Date: Thu, 24 Nov 2022 11:12:08 +0900
+Subject: block: mq-deadline: Do not break sequential write streams to zoned HDDs
+
+From: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+
+commit 015d02f48537cf2d1a65eeac50717566f9db6eec upstream.
+
+mq-deadline ensures an in order dispatching of write requests to zoned
+block devices using a per zone lock (a bit). This implies that for any
+purely sequential write workload, the drive is exercised most of the
+time at a maximum queue depth of one.
+
+However, when such sequential write workload crosses a zone boundary
+(when sequentially writing multiple contiguous zones), zone write
+locking may prevent the last write to one zone to be issued (as the
+previous write is still being executed) but allow the first write to the
+following zone to be issued (as that zone is not yet being writen and
+not locked). This result in an out of order delivery of the sequential
+write commands to the device every time a zone boundary is crossed.
+
+While such behavior does not break the sequential write constraint of
+zoned block devices (and does not generate any write error), some zoned
+hard-disks react badly to seeing these out of order writes, resulting in
+lower write throughput.
+
+This problem can be addressed by always dispatching the first request
+of a stream of sequential write requests, regardless of the zones
+targeted by these sequential writes. To do so, the function
+deadline_skip_seq_writes() is introduced and used in
+deadline_next_request() to select the next write command to issue if the
+target device is an HDD (blk_queue_nonrot() being false).
+deadline_fifo_request() is modified using the new
+deadline_earlier_request() and deadline_is_seq_write() helpers to ignore
+requests in the fifo list that have a preceding request in lba order
+that is sequential.
+
+With this fix, a sequential write workload executed with the following
+fio command:
+
+fio --name=seq-write --filename=/dev/sda --zonemode=zbd --direct=1 \
+ --size=68719476736 --ioengine=libaio --iodepth=32 --rw=write \
+ --bs=65536
+
+results in an increase from 225 MB/s to 250 MB/s of the write throughput
+of an SMR HDD (11% increase).
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
+Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
+Link: https://lore.kernel.org/r/20221124021208.242541-3-damien.lemoal@opensource.wdc.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/mq-deadline.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++----
+ 1 file changed, 62 insertions(+), 4 deletions(-)
+
+--- a/block/mq-deadline.c
++++ b/block/mq-deadline.c
+@@ -154,6 +154,20 @@ static u8 dd_rq_ioclass(struct request *
+ }
+
+ /*
++ * get the request before `rq' in sector-sorted order
++ */
++static inline struct request *
++deadline_earlier_request(struct request *rq)
++{
++ struct rb_node *node = rb_prev(&rq->rb_node);
++
++ if (node)
++ return rb_entry_rq(node);
++
++ return NULL;
++}
++
++/*
+ * get the request after `rq' in sector-sorted order
+ */
+ static inline struct request *
+@@ -289,6 +303,39 @@ static inline int deadline_check_fifo(st
+ }
+
+ /*
++ * Check if rq has a sequential request preceding it.
++ */
++static bool deadline_is_seq_writes(struct deadline_data *dd, struct request *rq)
++{
++ struct request *prev = deadline_earlier_request(rq);
++
++ if (!prev)
++ return false;
++
++ return blk_rq_pos(prev) + blk_rq_sectors(prev) == blk_rq_pos(rq);
++}
++
++/*
++ * Skip all write requests that are sequential from @rq, even if we cross
++ * a zone boundary.
++ */
++static struct request *deadline_skip_seq_writes(struct deadline_data *dd,
++ struct request *rq)
++{
++ sector_t pos = blk_rq_pos(rq);
++ sector_t skipped_sectors = 0;
++
++ while (rq) {
++ if (blk_rq_pos(rq) != pos + skipped_sectors)
++ break;
++ skipped_sectors += blk_rq_sectors(rq);
++ rq = deadline_latter_request(rq);
++ }
++
++ return rq;
++}
++
++/*
+ * For the specified data direction, return the next request to
+ * dispatch using arrival ordered lists.
+ */
+@@ -308,11 +355,16 @@ deadline_fifo_request(struct deadline_da
+
+ /*
+ * Look for a write request that can be dispatched, that is one with
+- * an unlocked target zone.
++ * an unlocked target zone. For some HDDs, breaking a sequential
++ * write stream can lead to lower throughput, so make sure to preserve
++ * sequential write streams, even if that stream crosses into the next
++ * zones and these zones are unlocked.
+ */
+ spin_lock_irqsave(&dd->zone_lock, flags);
+ list_for_each_entry(rq, &per_prio->fifo_list[DD_WRITE], queuelist) {
+- if (blk_req_can_dispatch_to_zone(rq))
++ if (blk_req_can_dispatch_to_zone(rq) &&
++ (blk_queue_nonrot(rq->q) ||
++ !deadline_is_seq_writes(dd, rq)))
+ goto out;
+ }
+ rq = NULL;
+@@ -342,13 +394,19 @@ deadline_next_request(struct deadline_da
+
+ /*
+ * Look for a write request that can be dispatched, that is one with
+- * an unlocked target zone.
++ * an unlocked target zone. For some HDDs, breaking a sequential
++ * write stream can lead to lower throughput, so make sure to preserve
++ * sequential write streams, even if that stream crosses into the next
++ * zones and these zones are unlocked.
+ */
+ spin_lock_irqsave(&dd->zone_lock, flags);
+ while (rq) {
+ if (blk_req_can_dispatch_to_zone(rq))
+ break;
+- rq = deadline_latter_request(rq);
++ if (blk_queue_nonrot(rq->q))
++ rq = deadline_latter_request(rq);
++ else
++ rq = deadline_skip_seq_writes(dd, rq);
+ }
+ spin_unlock_irqrestore(&dd->zone_lock, flags);
+
--- /dev/null
+From a85ceafd41927e41a4103d228a993df7edd8823b Mon Sep 17 00:00:00 2001
+From: Paulo Alcantara <pc@cjr.nz>
+Date: Fri, 16 Dec 2022 22:03:41 -0300
+Subject: cifs: fix confusing debug message
+
+From: Paulo Alcantara <pc@cjr.nz>
+
+commit a85ceafd41927e41a4103d228a993df7edd8823b upstream.
+
+Since rc was initialised to -ENOMEM in cifs_get_smb_ses(), when an
+existing smb session was found, free_xid() would be called and then
+print
+
+ CIFS: fs/cifs/connect.c: Existing tcp session with server found
+ CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 44 with uid: 0
+ CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
+ CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 44) rc = -12
+
+Fix this by initialising rc to 0 and then let free_xid() print this
+instead
+
+ CIFS: fs/cifs/connect.c: Existing tcp session with server found
+ CIFS: fs/cifs/connect.c: VFS: in cifs_get_smb_ses as Xid: 14 with uid: 0
+ CIFS: fs/cifs/connect.c: Existing smb sess found (status=1)
+ CIFS: fs/cifs/connect.c: VFS: leaving cifs_get_smb_ses (xid = 14) rc = 0
+
+Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Cc: stable@vger.kernel.org
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/connect.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/connect.c
++++ b/fs/cifs/connect.c
+@@ -1948,7 +1948,7 @@ cifs_set_cifscreds(struct smb3_fs_contex
+ struct cifs_ses *
+ cifs_get_smb_ses(struct TCP_Server_Info *server, struct smb3_fs_context *ctx)
+ {
+- int rc = -ENOMEM;
++ int rc = 0;
+ unsigned int xid;
+ struct cifs_ses *ses;
+ struct sockaddr_in *addr = (struct sockaddr_in *)&server->dstaddr;
+@@ -1990,6 +1990,8 @@ cifs_get_smb_ses(struct TCP_Server_Info
+ return ses;
+ }
+
++ rc = -ENOMEM;
++
+ cifs_dbg(FYI, "Existing smb sess not found\n");
+ ses = sesInfoAlloc();
+ if (ses == NULL)
--- /dev/null
+From 2bfd81043e944af0e52835ef6d9b41795af22341 Mon Sep 17 00:00:00 2001
+From: Steve French <stfrench@microsoft.com>
+Date: Sun, 11 Dec 2022 13:54:21 -0600
+Subject: cifs: fix missing display of three mount options
+
+From: Steve French <stfrench@microsoft.com>
+
+commit 2bfd81043e944af0e52835ef6d9b41795af22341 upstream.
+
+Three mount options: "tcpnodelay" and "noautotune" and "noblocksend"
+were not displayed when passed in on cifs/smb3 mounts (e.g. displayed
+in /proc/mounts e.g.). No change to defaults so these are not
+displayed if not specified on mount.
+
+Cc: stable@vger.kernel.org
+Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
+Signed-off-by: Steve French <stfrench@microsoft.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/cifs/cifsfs.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+--- a/fs/cifs/cifsfs.c
++++ b/fs/cifs/cifsfs.c
+@@ -656,9 +656,15 @@ cifs_show_options(struct seq_file *s, st
+ seq_printf(s, ",echo_interval=%lu",
+ tcon->ses->server->echo_interval / HZ);
+
+- /* Only display max_credits if it was overridden on mount */
++ /* Only display the following if overridden on mount */
+ if (tcon->ses->server->max_credits != SMB2_MAX_CREDITS_AVAILABLE)
+ seq_printf(s, ",max_credits=%u", tcon->ses->server->max_credits);
++ if (tcon->ses->server->tcp_nodelay)
++ seq_puts(s, ",tcpnodelay");
++ if (tcon->ses->server->noautotune)
++ seq_puts(s, ",noautotune");
++ if (tcon->ses->server->noblocksnd)
++ seq_puts(s, ",noblocksend");
+
+ if (tcon->snapshot_time)
+ seq_printf(s, ",snapshot=%llu", tcon->snapshot_time);
--- /dev/null
+From fd3dc56253acbe9c641a66d312d8393cd55eb04c Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Fri, 9 Dec 2022 10:52:47 -0500
+Subject: ftrace/x86: Add back ftrace_expected for ftrace bug reports
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit fd3dc56253acbe9c641a66d312d8393cd55eb04c upstream.
+
+After someone reported a bug report with a failed modification due to the
+expected value not matching what was found, it came to my attention that
+the ftrace_expected is no longer set when that happens. This makes for
+debugging the issue a bit more difficult.
+
+Set ftrace_expected to the expected code before calling ftrace_bug, so
+that it shows what was expected and why it failed.
+
+Link: https://lore.kernel.org/all/CA+wXwBQ-VhK+hpBtYtyZP-NiX4g8fqRRWithFOHQW-0coQ3vLg@mail.gmail.com/
+Link: https://lore.kernel.org/linux-trace-kernel/20221209105247.01d4e51d@gandalf.local.home
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Andrew Morton <akpm@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: "x86@kernel.org" <x86@kernel.org>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Ingo Molnar <mingo@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 768ae4406a5c ("x86/ftrace: Use text_poke()")
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/ftrace.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/x86/kernel/ftrace.c
++++ b/arch/x86/kernel/ftrace.c
+@@ -219,7 +219,9 @@ void ftrace_replace_code(int enable)
+
+ ret = ftrace_verify_code(rec->ip, old);
+ if (ret) {
++ ftrace_expected = old;
+ ftrace_bug(ret, rec);
++ ftrace_expected = NULL;
+ return;
+ }
+ }
--- /dev/null
+From 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 6 Oct 2022 00:19:56 +0000
+Subject: KVM: nVMX: Inject #GP, not #UD, if "generic" VMXON CR0/CR4 check fails
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 9cc409325ddd776f6fd6293d5ce93ce1248af6e4 upstream.
+
+Inject #GP for if VMXON is attempting with a CR0/CR4 that fails the
+generic "is CRx valid" check, but passes the CR4.VMXE check, and do the
+generic checks _after_ handling the post-VMXON VM-Fail.
+
+The CR4.VMXE check, and all other #UD cases, are special pre-conditions
+that are enforced prior to pivoting on the current VMX mode, i.e. occur
+before interception if VMXON is attempted in VMX non-root mode.
+
+All other CR0/CR4 checks generate #GP and effectively have lower priority
+than the post-VMXON check.
+
+Per the SDM:
+
+ IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ...
+ THEN #UD;
+ ELSIF not in VMX operation
+ THEN
+ IF (CPL > 0) or (in A20M mode) or
+ (the values of CR0 and CR4 are not supported in VMX operation)
+ THEN #GP(0);
+ ELSIF in VMX non-root operation
+ THEN VMexit;
+ ELSIF CPL > 0
+ THEN #GP(0);
+ ELSE VMfail("VMXON executed in VMX root operation");
+ FI;
+
+which, if re-written without ELSIF, yields:
+
+ IF (register operand) or (CR0.PE = 0) or (CR4.VMXE = 0) or ...
+ THEN #UD
+
+ IF in VMX non-root operation
+ THEN VMexit;
+
+ IF CPL > 0
+ THEN #GP(0)
+
+ IF in VMX operation
+ THEN VMfail("VMXON executed in VMX root operation");
+
+ IF (in A20M mode) or
+ (the values of CR0 and CR4 are not supported in VMX operation)
+ THEN #GP(0);
+
+Note, KVM unconditionally forwards VMXON VM-Exits that occur in L2 to L1,
+i.e. there is no need to check the vCPU is not in VMX non-root mode. Add
+a comment to explain why unconditionally forwarding such exits is
+functionally correct.
+
+Reported-by: Eric Li <ercli@ucdavis.edu>
+Fixes: c7d855c2aff2 ("KVM: nVMX: Inject #UD if VMXON is attempted with incompatible CR0/CR4")
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Link: https://lore.kernel.org/r/20221006001956.329314-1-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/nested.c | 44 +++++++++++++++++++++++++++++++++-----------
+ 1 file changed, 33 insertions(+), 11 deletions(-)
+
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -4970,24 +4970,35 @@ static int handle_vmon(struct kvm_vcpu *
+ | FEAT_CTL_VMX_ENABLED_OUTSIDE_SMX;
+
+ /*
+- * Note, KVM cannot rely on hardware to perform the CR0/CR4 #UD checks
+- * that have higher priority than VM-Exit (see Intel SDM's pseudocode
+- * for VMXON), as KVM must load valid CR0/CR4 values into hardware while
+- * running the guest, i.e. KVM needs to check the _guest_ values.
++ * Manually check CR4.VMXE checks, KVM must force CR4.VMXE=1 to enter
++ * the guest and so cannot rely on hardware to perform the check,
++ * which has higher priority than VM-Exit (see Intel SDM's pseudocode
++ * for VMXON).
+ *
+- * Rely on hardware for the other two pre-VM-Exit checks, !VM86 and
+- * !COMPATIBILITY modes. KVM may run the guest in VM86 to emulate Real
+- * Mode, but KVM will never take the guest out of those modes.
++ * Rely on hardware for the other pre-VM-Exit checks, CR0.PE=1, !VM86
++ * and !COMPATIBILITY modes. For an unrestricted guest, KVM doesn't
++ * force any of the relevant guest state. For a restricted guest, KVM
++ * does force CR0.PE=1, but only to also force VM86 in order to emulate
++ * Real Mode, and so there's no need to check CR0.PE manually.
+ */
+- if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
+- !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
++ if (!kvm_read_cr4_bits(vcpu, X86_CR4_VMXE)) {
+ kvm_queue_exception(vcpu, UD_VECTOR);
+ return 1;
+ }
+
+ /*
+- * CPL=0 and all other checks that are lower priority than VM-Exit must
+- * be checked manually.
++ * The CPL is checked for "not in VMX operation" and for "in VMX root",
++ * and has higher priority than the VM-Fail due to being post-VMXON,
++ * i.e. VMXON #GPs outside of VMX non-root if CPL!=0. In VMX non-root,
++ * VMXON causes VM-Exit and KVM unconditionally forwards VMXON VM-Exits
++ * from L2 to L1, i.e. there's no need to check for the vCPU being in
++ * VMX non-root.
++ *
++ * Forwarding the VM-Exit unconditionally, i.e. without performing the
++ * #UD checks (see above), is functionally ok because KVM doesn't allow
++ * L1 to run L2 without CR4.VMXE=0, and because KVM never modifies L2's
++ * CR0 or CR4, i.e. it's L2's responsibility to emulate #UDs that are
++ * missed by hardware due to shadowing CR0 and/or CR4.
+ */
+ if (vmx_get_cpl(vcpu)) {
+ kvm_inject_gp(vcpu, 0);
+@@ -4997,6 +5008,17 @@ static int handle_vmon(struct kvm_vcpu *
+ if (vmx->nested.vmxon)
+ return nested_vmx_fail(vcpu, VMXERR_VMXON_IN_VMX_ROOT_OPERATION);
+
++ /*
++ * Invalid CR0/CR4 generates #GP. These checks are performed if and
++ * only if the vCPU isn't already in VMX operation, i.e. effectively
++ * have lower priority than the VM-Fail above.
++ */
++ if (!nested_host_cr0_valid(vcpu, kvm_read_cr0(vcpu)) ||
++ !nested_host_cr4_valid(vcpu, kvm_read_cr4(vcpu))) {
++ kvm_inject_gp(vcpu, 0);
++ return 1;
++ }
++
+ if ((vmx->msr_ia32_feature_control & VMXON_NEEDED_FEATURES)
+ != VMXON_NEEDED_FEATURES) {
+ kvm_inject_gp(vcpu, 0);
--- /dev/null
+From 31de69f4eea77b28a9724b3fa55aae104fc91fc7 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Tue, 13 Dec 2022 06:23:03 +0000
+Subject: KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 31de69f4eea77b28a9724b3fa55aae104fc91fc7 upstream.
+
+Set ENABLE_USR_WAIT_PAUSE in KVM's supported VMX MSR configuration if the
+feature is supported in hardware and enabled in KVM's base, non-nested
+configuration, i.e. expose ENABLE_USR_WAIT_PAUSE to L1 if it's supported.
+This fixes a bug where saving/restoring, i.e. migrating, a vCPU will fail
+if WAITPKG (the associated CPUID feature) is enabled for the vCPU, and
+obviously allows L1 to enable the feature for L2.
+
+KVM already effectively exposes ENABLE_USR_WAIT_PAUSE to L1 by stuffing
+the allowed-1 control ina vCPU's virtual MSR_IA32_VMX_PROCBASED_CTLS2 when
+updating secondary controls in response to KVM_SET_CPUID(2), but (a) that
+depends on flawed code (KVM shouldn't touch VMX MSRs in response to CPUID
+updates) and (b) runs afoul of vmx_restore_control_msr()'s restriction
+that the guest value must be a strict subset of the supported host value.
+
+Although no past commit explicitly enabled nested support for WAITPKG,
+doing so is safe and functionally correct from an architectural
+perspective as no additional KVM support is needed to virtualize TPAUSE,
+UMONITOR, and UMWAIT for L2 relative to L1, and KVM already forwards
+VM-Exits to L1 as necessary (commit bf653b78f960, "KVM: vmx: Introduce
+handle_unexpected_vmexit and handle WAITPKG vmexit").
+
+Note, KVM always keeps the hosts MSR_IA32_UMWAIT_CONTROL resident in
+hardware, i.e. always runs both L1 and L2 with the host's power management
+settings for TPAUSE and UMWAIT. See commit bf09fb6cba4f ("KVM: VMX: Stop
+context switching MSR_IA32_UMWAIT_CONTROL") for more details.
+
+Fixes: e69e72faa3a0 ("KVM: x86: Add support for user wait instructions")
+Cc: stable@vger.kernel.org
+Reported-by: Aaron Lewis <aaronlewis@google.com>
+Reported-by: Yu Zhang <yu.c.zhang@linux.intel.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Message-Id: <20221213062306.667649-2-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/nested.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/nested.c
++++ b/arch/x86/kvm/vmx/nested.c
+@@ -6666,7 +6666,8 @@ void nested_vmx_setup_ctls_msrs(struct n
+ SECONDARY_EXEC_ENABLE_INVPCID |
+ SECONDARY_EXEC_RDSEED_EXITING |
+ SECONDARY_EXEC_XSAVES |
+- SECONDARY_EXEC_TSC_SCALING;
++ SECONDARY_EXEC_TSC_SCALING |
++ SECONDARY_EXEC_ENABLE_USR_WAIT_PAUSE;
+
+ /*
+ * We can emulate "VMCS shadowing," even if the hardware
--- /dev/null
+From eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Fri, 30 Sep 2022 23:31:32 +0000
+Subject: KVM: VMX: Resume guest immediately when injecting #GP on ECREATE
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit eb3992e833d3a17f9b0a3e0371d0b1d3d566f740 upstream.
+
+Resume the guest immediately when injecting a #GP on ECREATE due to an
+invalid enclave size, i.e. don't attempt ECREATE in the host. The #GP is
+a terminal fault, e.g. skipping the instruction if ECREATE is successful
+would result in KVM injecting #GP on the instruction following ECREATE.
+
+Fixes: 70210c044b4e ("KVM: VMX: Add SGX ENCLS[ECREATE] handler to enforce CPUID restrictions")
+Cc: stable@vger.kernel.org
+Cc: Kai Huang <kai.huang@intel.com>
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Kai Huang <kai.huang@intel.com>
+Link: https://lore.kernel.org/r/20220930233132.1723330-1-seanjc@google.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/vmx/sgx.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/kvm/vmx/sgx.c
++++ b/arch/x86/kvm/vmx/sgx.c
+@@ -188,8 +188,10 @@ static int __handle_encls_ecreate(struct
+ /* Enforce CPUID restriction on max enclave size. */
+ max_size_log2 = (attributes & SGX_ATTR_MODE64BIT) ? sgx_12_0->edx >> 8 :
+ sgx_12_0->edx;
+- if (size >= BIT_ULL(max_size_log2))
++ if (size >= BIT_ULL(max_size_log2)) {
+ kvm_inject_gp(vcpu, 0);
++ return 1;
++ }
+
+ /*
+ * sgx_virt_ecreate() returns:
--- /dev/null
+From 6b0d0477fce747d4137aa65856318b55fba72198 Mon Sep 17 00:00:00 2001
+From: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+Date: Tue, 26 Apr 2022 06:29:19 +0100
+Subject: media: dvb-core: Fix double free in dvb_register_device()
+
+From: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+
+commit 6b0d0477fce747d4137aa65856318b55fba72198 upstream.
+
+In function dvb_register_device() -> dvb_register_media_device() ->
+dvb_create_media_entity(), dvb->entity is allocated and initialized. If
+the initialization fails, it frees the dvb->entity, and return an error
+code. The caller takes the error code and handles the error by calling
+dvb_media_device_free(), which unregisters the entity and frees the
+field again if it is not NULL. As dvb->entity may not NULLed in
+dvb_create_media_entity() when the allocation of dvbdev->pad fails, a
+double free may occur. This may also cause an Use After free in
+media_device_unregister_entity().
+
+Fix this by storing NULL to dvb->entity when it is freed.
+
+Link: https://lore.kernel.org/linux-media/20220426052921.2088416-1-keitasuzuki.park@sslab.ics.keio.ac.jp
+Fixes: fcd5ce4b3936 ("media: dvb-core: fix a memory leak bug")
+Cc: stable@vger.kernel.org
+Cc: Wenwen Wang <wenwen@cs.uga.edu>
+Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp>
+Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/dvb-core/dvbdev.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/media/dvb-core/dvbdev.c
++++ b/drivers/media/dvb-core/dvbdev.c
+@@ -345,6 +345,7 @@ static int dvb_create_media_entity(struc
+ GFP_KERNEL);
+ if (!dvbdev->pads) {
+ kfree(dvbdev->entity);
++ dvbdev->entity = NULL;
+ return -ENOMEM;
+ }
+ }
--- /dev/null
+From fd3d91ab1c6ab0628fe642dd570b56302c30a792 Mon Sep 17 00:00:00 2001
+From: Takashi Iwai <tiwai@suse.de>
+Date: Mon, 31 Oct 2022 11:02:45 +0100
+Subject: media: dvb-core: Fix UAF due to refcount races at releasing
+
+From: Takashi Iwai <tiwai@suse.de>
+
+commit fd3d91ab1c6ab0628fe642dd570b56302c30a792 upstream.
+
+The dvb-core tries to sync the releases of opened files at
+dvb_dmxdev_release() with two refcounts: dvbdev->users and
+dvr_dvbdev->users. A problem is present in those two syncs: when yet
+another dvb_demux_open() is called during those sync waits,
+dvb_demux_open() continues to process even if the device is being
+closed. This includes the increment of the former refcount, resulting
+in the leftover refcount after the sync of the latter refcount at
+dvb_dmxdev_release(). It ends up with use-after-free, since the
+function believes that all usages were gone and releases the
+resources.
+
+This patch addresses the problem by adding the check of dmxdev->exit
+flag at dvb_demux_open(), just like dvb_dvr_open() already does. With
+the exit flag check, the second call of dvb_demux_open() fails, hence
+the further corruption can be avoided.
+
+Also for avoiding the races of the dmxdev->exit flag reference, this
+patch serializes the dmxdev->exit set up and the sync waits with the
+dmxdev->mutex lock at dvb_dmxdev_release(). Without the mutex lock,
+dvb_demux_open() (or dvb_dvr_open()) may run concurrently with
+dvb_dmxdev_release(), which allows to skip the exit flag check and
+continue the open process that is being closed.
+
+CVE-2022-41218 is assigned to those bugs above.
+
+Reported-by: Hyunwoo Kim <imv4bel@gmail.com>
+Cc: <stable@vger.kernel.org>
+Link: https://lore.kernel.org/20220908132754.30532-1-tiwai@suse.de
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/dvb-core/dmxdev.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+--- a/drivers/media/dvb-core/dmxdev.c
++++ b/drivers/media/dvb-core/dmxdev.c
+@@ -800,6 +800,11 @@ static int dvb_demux_open(struct inode *
+ if (mutex_lock_interruptible(&dmxdev->mutex))
+ return -ERESTARTSYS;
+
++ if (dmxdev->exit) {
++ mutex_unlock(&dmxdev->mutex);
++ return -ENODEV;
++ }
++
+ for (i = 0; i < dmxdev->filternum; i++)
+ if (dmxdev->filter[i].state == DMXDEV_STATE_FREE)
+ break;
+@@ -1458,7 +1463,10 @@ EXPORT_SYMBOL(dvb_dmxdev_init);
+
+ void dvb_dmxdev_release(struct dmxdev *dmxdev)
+ {
++ mutex_lock(&dmxdev->mutex);
+ dmxdev->exit = 1;
++ mutex_unlock(&dmxdev->mutex);
++
+ if (dmxdev->dvbdev->users > 1) {
+ wait_event(dmxdev->dvbdev->wait_queue,
+ dmxdev->dvbdev->users == 1);
--- /dev/null
+From 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 Mon Sep 17 00:00:00 2001
+From: Ian Abbott <abbotti@mev.co.uk>
+Date: Thu, 27 Oct 2022 17:32:49 +0100
+Subject: rtc: ds1347: fix value written to century register
+
+From: Ian Abbott <abbotti@mev.co.uk>
+
+commit 4dfe05bdc1ade79b943d4979a2e2a8b5ef68fbb5 upstream.
+
+In `ds1347_set_time()`, the wrong value is being written to the
+`DS1347_CENTURY_REG` register. It needs to be converted to BCD. Fix
+it.
+
+Fixes: 147dae76dbb9 ("rtc: ds1347: handle century register")
+Cc: <stable@vger.kernel.org> # v5.5+
+Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
+Link: https://lore.kernel.org/r/20221027163249.447416-1-abbotti@mev.co.uk
+Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/rtc/rtc-ds1347.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/rtc/rtc-ds1347.c
++++ b/drivers/rtc/rtc-ds1347.c
+@@ -112,7 +112,7 @@ static int ds1347_set_time(struct device
+ return err;
+
+ century = (dt->tm_year / 100) + 19;
+- err = regmap_write(map, DS1347_CENTURY_REG, century);
++ err = regmap_write(map, DS1347_CENTURY_REG, bin2bcd(century));
+ if (err)
+ return err;
+
tracing-hist-fix-out-of-bound-write-on-action_data.var_ref_idx.patch
perf-core-call-lsm-hook-after-copying-perf_event_attr.patch
of-kexec-fix-reading-32-bit-linux-initrd-start-end-values.patch
+kvm-vmx-resume-guest-immediately-when-injecting-gp-on-ecreate.patch
+kvm-nvmx-inject-gp-not-ud-if-generic-vmxon-cr0-cr4-check-fails.patch
+kvm-nvmx-properly-expose-enable_usr_wait_pause-control-to-l1.patch
+x86-microcode-intel-do-not-retry-microcode-reloading-on-the-aps.patch
+ftrace-x86-add-back-ftrace_expected-for-ftrace-bug-reports.patch
+x86-kprobes-fix-kprobes-instruction-boudary-check-with-config_rethunk.patch
+x86-kprobes-fix-optprobe-optimization-check-with-config_rethunk.patch
+tracing-fix-race-where-eprobes-can-be-called-before-the-event.patch
+tracing-fix-complicated-dependency-of-config_tracer_max_trace.patch
+tracing-hist-fix-wrong-return-value-in-parse_action_params.patch
+tracing-probes-handle-system-names-with-hyphens.patch
+tracing-fix-infinite-loop-in-tracing_read_pipe-on-overflowed-print_trace_line.patch
+staging-media-tegra-video-fix-chan-mipi-value-on-error.patch
+staging-media-tegra-video-fix-device_node-use-after-free.patch
+arm-9256-1-nwfpe-avoid-compiler-generated-__aeabi_uldivmod.patch
+media-dvb-core-fix-double-free-in-dvb_register_device.patch
+media-dvb-core-fix-uaf-due-to-refcount-races-at-releasing.patch
+cifs-fix-confusing-debug-message.patch
+cifs-fix-missing-display-of-three-mount-options.patch
+rtc-ds1347-fix-value-written-to-century-register.patch
+block-mq-deadline-do-not-break-sequential-write-streams-to-zoned-hdds.patch
--- /dev/null
+From 10b5ce6743c839fa75336042c64e2479caec9430 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Wed, 2 Nov 2022 12:01:01 +0100
+Subject: staging: media: tegra-video: fix chan->mipi value on error
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+commit 10b5ce6743c839fa75336042c64e2479caec9430 upstream.
+
+chan->mipi takes the return value of tegra_mipi_request() which can be a
+valid pointer or an error. However chan->mipi is checked in several places,
+including error-cleanup code in tegra_csi_channels_cleanup(), as 'if
+(chan->mipi)', which suggests the initial intent was that chan->mipi should
+be either NULL or a valid pointer, never an error. As a consequence,
+cleanup code in case of tegra_mipi_request() errors would dereference an
+invalid pointer.
+
+Fix by ensuring chan->mipi always contains either NULL or a void pointer.
+
+Also add that to the documentation.
+
+Fixes: 523c857e34ce ("media: tegra-video: Add CSI MIPI pads calibration")
+Cc: stable@vger.kernel.org
+Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/media/tegra-video/csi.c | 1 +
+ drivers/staging/media/tegra-video/csi.h | 2 +-
+ 2 files changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/media/tegra-video/csi.c
++++ b/drivers/staging/media/tegra-video/csi.c
+@@ -448,6 +448,7 @@ static int tegra_csi_channel_alloc(struc
+ chan->mipi = tegra_mipi_request(csi->dev, node);
+ if (IS_ERR(chan->mipi)) {
+ ret = PTR_ERR(chan->mipi);
++ chan->mipi = NULL;
+ dev_err(csi->dev, "failed to get mipi device: %d\n", ret);
+ }
+
+--- a/drivers/staging/media/tegra-video/csi.h
++++ b/drivers/staging/media/tegra-video/csi.h
+@@ -56,7 +56,7 @@ struct tegra_csi;
+ * @framerate: active framerate for TPG
+ * @h_blank: horizontal blanking for TPG active format
+ * @v_blank: vertical blanking for TPG active format
+- * @mipi: mipi device for corresponding csi channel pads
++ * @mipi: mipi device for corresponding csi channel pads, or NULL if not applicable (TPG, error)
+ * @pixel_rate: active pixel rate from the sensor on this channel
+ */
+ struct tegra_csi_channel {
--- /dev/null
+From c4d344163c3a7f90712525f931a6c016bbb35e18 Mon Sep 17 00:00:00 2001
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Date: Wed, 2 Nov 2022 12:01:02 +0100
+Subject: staging: media: tegra-video: fix device_node use after free
+
+From: Luca Ceresoli <luca.ceresoli@bootlin.com>
+
+commit c4d344163c3a7f90712525f931a6c016bbb35e18 upstream.
+
+At probe time this code path is followed:
+
+ * tegra_csi_init
+ * tegra_csi_channels_alloc
+ * for_each_child_of_node(node, channel) -- iterates over channels
+ * automatically gets 'channel'
+ * tegra_csi_channel_alloc()
+ * saves into chan->of_node a pointer to the channel OF node
+ * automatically gets and puts 'channel'
+ * now the node saved in chan->of_node has refcount 0, can disappear
+ * tegra_csi_channels_init
+ * iterates over channels
+ * tegra_csi_channel_init -- uses chan->of_node
+
+After that, chan->of_node keeps storing the node until the device is
+removed.
+
+of_node_get() the node and of_node_put() it during teardown to avoid any
+risk.
+
+Fixes: 1ebaeb09830f ("media: tegra-video: Add support for external sensor capture")
+Cc: stable@vger.kernel.org
+Cc: Sowjanya Komatineni <skomatineni@nvidia.com>
+Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/staging/media/tegra-video/csi.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/staging/media/tegra-video/csi.c
++++ b/drivers/staging/media/tegra-video/csi.c
+@@ -433,7 +433,7 @@ static int tegra_csi_channel_alloc(struc
+ for (i = 0; i < chan->numgangports; i++)
+ chan->csi_port_nums[i] = port_num + i * CSI_PORTS_PER_BRICK;
+
+- chan->of_node = node;
++ chan->of_node = of_node_get(node);
+ chan->numpads = num_pads;
+ if (num_pads & 0x2) {
+ chan->pads[0].flags = MEDIA_PAD_FL_SINK;
+@@ -641,6 +641,7 @@ static void tegra_csi_channels_cleanup(s
+ media_entity_cleanup(&subdev->entity);
+ }
+
++ of_node_put(chan->of_node);
+ list_del(&chan->list);
+ kfree(chan);
+ }
--- /dev/null
+From e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Tue, 6 Dec 2022 23:18:01 +0900
+Subject: tracing: Fix complicated dependency of CONFIG_TRACER_MAX_TRACE
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit e25e43a4e5d8cb2323553d8b6a7ba08d2ebab21f upstream.
+
+Both CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER partially enables the
+CONFIG_TRACER_MAX_TRACE code, but that is complicated and has
+introduced a bug; It declares tracing_max_lat_fops data structure outside
+of #ifdefs, but since it is defined only when CONFIG_TRACER_MAX_TRACE=y
+or CONFIG_HWLAT_TRACER=y, if only CONFIG_OSNOISE_TRACER=y, that
+declaration comes to a definition(!).
+
+To fix this issue, and do not repeat the similar problem, makes
+CONFIG_OSNOISE_TRACER and CONFIG_HWLAT_TRACER enables the
+CONFIG_TRACER_MAX_TRACE always. It has there benefits;
+- Fix the tracing_max_lat_fops bug
+- Simplify the #ifdefs
+- CONFIG_TRACER_MAX_TRACE code is fully enabled, or not.
+
+Link: https://lore.kernel.org/linux-trace-kernel/167033628155.4111793.12185405690820208159.stgit@devnote3
+
+Fixes: 424b650f35c7 ("tracing: Fix missing osnoise tracer on max_latency")
+Cc: Daniel Bristot de Oliveira <bristot@kernel.org>
+Cc: stable@vger.kernel.org
+Reported-by: David Howells <dhowells@redhat.com>
+Reported-by: kernel test robot <lkp@intel.com>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Link: https://lore.kernel.org/all/166992525941.1716618.13740663757583361463.stgit@warthog.procyon.org.uk/ (original thread and v1)
+Link: https://lore.kernel.org/all/202212052253.VuhZ2ulJ-lkp@intel.com/T/#u (v1 error report)
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/Kconfig | 2 ++
+ kernel/trace/trace.c | 23 +++++++++++++----------
+ kernel/trace/trace.h | 8 +++-----
+ 3 files changed, 18 insertions(+), 15 deletions(-)
+
+--- a/kernel/trace/Kconfig
++++ b/kernel/trace/Kconfig
+@@ -328,6 +328,7 @@ config SCHED_TRACER
+ config HWLAT_TRACER
+ bool "Tracer to detect hardware latencies (like SMIs)"
+ select GENERIC_TRACER
++ select TRACER_MAX_TRACE
+ help
+ This tracer, when enabled will create one or more kernel threads,
+ depending on what the cpumask file is set to, which each thread
+@@ -363,6 +364,7 @@ config HWLAT_TRACER
+ config OSNOISE_TRACER
+ bool "OS Noise tracer"
+ select GENERIC_TRACER
++ select TRACER_MAX_TRACE
+ help
+ In the context of high-performance computing (HPC), the Operating
+ System Noise (osnoise) refers to the interference experienced by an
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -1409,6 +1409,7 @@ int tracing_snapshot_cond_disable(struct
+ return false;
+ }
+ EXPORT_SYMBOL_GPL(tracing_snapshot_cond_disable);
++#define free_snapshot(tr) do { } while (0)
+ #endif /* CONFIG_TRACER_SNAPSHOT */
+
+ void tracer_tracing_off(struct trace_array *tr)
+@@ -1679,6 +1680,8 @@ static ssize_t trace_seq_to_buffer(struc
+ }
+
+ unsigned long __read_mostly tracing_thresh;
++
++#ifdef CONFIG_TRACER_MAX_TRACE
+ static const struct file_operations tracing_max_lat_fops;
+
+ #ifdef LATENCY_FS_NOTIFY
+@@ -1735,18 +1738,14 @@ void latency_fsnotify(struct trace_array
+ irq_work_queue(&tr->fsnotify_irqwork);
+ }
+
+-#elif defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+- || defined(CONFIG_OSNOISE_TRACER)
++#else /* !LATENCY_FS_NOTIFY */
+
+ #define trace_create_maxlat_file(tr, d_tracer) \
+ trace_create_file("tracing_max_latency", TRACE_MODE_WRITE, \
+ d_tracer, &tr->max_latency, &tracing_max_lat_fops)
+
+-#else
+-#define trace_create_maxlat_file(tr, d_tracer) do { } while (0)
+ #endif
+
+-#ifdef CONFIG_TRACER_MAX_TRACE
+ /*
+ * Copy the new maximum trace into the separate maximum-trace
+ * structure. (this way the maximum trace is permanently saved,
+@@ -1821,14 +1820,15 @@ update_max_tr(struct trace_array *tr, st
+ ring_buffer_record_off(tr->max_buffer.buffer);
+
+ #ifdef CONFIG_TRACER_SNAPSHOT
+- if (tr->cond_snapshot && !tr->cond_snapshot->update(tr, cond_data))
+- goto out_unlock;
++ if (tr->cond_snapshot && !tr->cond_snapshot->update(tr, cond_data)) {
++ arch_spin_unlock(&tr->max_lock);
++ return;
++ }
+ #endif
+ swap(tr->array_buffer.buffer, tr->max_buffer.buffer);
+
+ __update_max_tr(tr, tsk, cpu);
+
+- out_unlock:
+ arch_spin_unlock(&tr->max_lock);
+ }
+
+@@ -1875,6 +1875,7 @@ update_max_tr_single(struct trace_array
+ __update_max_tr(tr, tsk, cpu);
+ arch_spin_unlock(&tr->max_lock);
+ }
++
+ #endif /* CONFIG_TRACER_MAX_TRACE */
+
+ static int wait_on_pipe(struct trace_iterator *iter, int full)
+@@ -6536,7 +6537,7 @@ out:
+ return ret;
+ }
+
+-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)
++#ifdef CONFIG_TRACER_MAX_TRACE
+
+ static ssize_t
+ tracing_max_lat_read(struct file *filp, char __user *ubuf,
+@@ -7560,7 +7561,7 @@ static const struct file_operations trac
+ .llseek = generic_file_llseek,
+ };
+
+-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER)
++#ifdef CONFIG_TRACER_MAX_TRACE
+ static const struct file_operations tracing_max_lat_fops = {
+ .open = tracing_open_generic,
+ .read = tracing_max_lat_read,
+@@ -9549,7 +9550,9 @@ init_tracer_tracefs(struct trace_array *
+
+ create_trace_options_dir(tr);
+
++#ifdef CONFIG_TRACER_MAX_TRACE
+ trace_create_maxlat_file(tr, d_tracer);
++#endif
+
+ if (ftrace_create_function_files(tr, d_tracer))
+ MEM_FAIL(1, "Could not allocate function filter files");
+--- a/kernel/trace/trace.h
++++ b/kernel/trace/trace.h
+@@ -309,8 +309,7 @@ struct trace_array {
+ struct array_buffer max_buffer;
+ bool allocated_snapshot;
+ #endif
+-#if defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+- || defined(CONFIG_OSNOISE_TRACER)
++#ifdef CONFIG_TRACER_MAX_TRACE
+ unsigned long max_latency;
+ #ifdef CONFIG_FSNOTIFY
+ struct dentry *d_max_latency;
+@@ -688,12 +687,11 @@ void update_max_tr(struct trace_array *t
+ void *cond_data);
+ void update_max_tr_single(struct trace_array *tr,
+ struct task_struct *tsk, int cpu);
+-#endif /* CONFIG_TRACER_MAX_TRACE */
+
+-#if (defined(CONFIG_TRACER_MAX_TRACE) || defined(CONFIG_HWLAT_TRACER) \
+- || defined(CONFIG_OSNOISE_TRACER)) && defined(CONFIG_FSNOTIFY)
++#ifdef CONFIG_FSNOTIFY
+ #define LATENCY_FS_NOTIFY
+ #endif
++#endif /* CONFIG_TRACER_MAX_TRACE */
+
+ #ifdef LATENCY_FS_NOTIFY
+ void latency_fsnotify(struct trace_array *tr);
--- /dev/null
+From c1ac03af6ed45d05786c219d102f37eb44880f28 Mon Sep 17 00:00:00 2001
+From: Yang Jihong <yangjihong1@huawei.com>
+Date: Tue, 29 Nov 2022 19:30:09 +0800
+Subject: tracing: Fix infinite loop in tracing_read_pipe on overflowed print_trace_line
+
+From: Yang Jihong <yangjihong1@huawei.com>
+
+commit c1ac03af6ed45d05786c219d102f37eb44880f28 upstream.
+
+print_trace_line may overflow seq_file buffer. If the event is not
+consumed, the while loop keeps peeking this event, causing a infinite loop.
+
+Link: https://lkml.kernel.org/r/20221129113009.182425-1-yangjihong1@huawei.com
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 088b1e427dbba ("ftrace: pipe fixes")
+Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 15 ++++++++++++++-
+ 1 file changed, 14 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -6764,7 +6764,20 @@ waitagain:
+
+ ret = print_trace_line(iter);
+ if (ret == TRACE_TYPE_PARTIAL_LINE) {
+- /* don't print partial lines */
++ /*
++ * If one print_trace_line() fills entire trace_seq in one shot,
++ * trace_seq_to_user() will returns -EBUSY because save_len == 0,
++ * In this case, we need to consume it, otherwise, loop will peek
++ * this event next time, resulting in an infinite loop.
++ */
++ if (save_len == 0) {
++ iter->seq.full = 0;
++ trace_seq_puts(&iter->seq, "[LINE TOO BIG]\n");
++ trace_consume(iter);
++ break;
++ }
++
++ /* In other cases, don't print partial lines */
+ iter->seq.seq.len = save_len;
+ break;
+ }
--- /dev/null
+From d5f30a7da8ea8e6450250275cec5670cee3c4264 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Thu, 17 Nov 2022 21:42:49 -0500
+Subject: tracing: Fix race where eprobes can be called before the event
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit d5f30a7da8ea8e6450250275cec5670cee3c4264 upstream.
+
+The flag that tells the event to call its triggers after reading the event
+is set for eprobes after the eprobe is enabled. This leads to a race where
+the eprobe may be triggered at the beginning of the event where the record
+information is NULL. The eprobe then dereferences the NULL record causing
+a NULL kernel pointer bug.
+
+Test for a NULL record to keep this from happening.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221116192552.1066630-1-rafaelmendsr@gmail.com/
+Link: https://lore.kernel.org/all/20221117214249.2addbe10@gandalf.local.home/
+
+Cc: stable@vger.kernel.org
+Fixes: 7491e2c442781 ("tracing: Add a probe that attaches to trace events")
+Reported-by: Rafael Mendonca <rafaelmendsr@gmail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_eprobe.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/kernel/trace/trace_eprobe.c
++++ b/kernel/trace/trace_eprobe.c
+@@ -570,6 +570,9 @@ static void eprobe_trigger_func(struct e
+ if (unlikely(!rec))
+ return;
+
++ if (unlikely(!rec))
++ return;
++
+ __eprobe_trace_func(edata, rec);
+ }
+
--- /dev/null
+From 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 Mon Sep 17 00:00:00 2001
+From: Zheng Yejian <zhengyejian1@huawei.com>
+Date: Wed, 7 Dec 2022 11:46:35 +0800
+Subject: tracing/hist: Fix wrong return value in parse_action_params()
+
+From: Zheng Yejian <zhengyejian1@huawei.com>
+
+commit 2cc6a528882d0e0ccbc1bca5f95b8c963cedac54 upstream.
+
+When number of synth fields is more than SYNTH_FIELDS_MAX,
+parse_action_params() should return -EINVAL.
+
+Link: https://lore.kernel.org/linux-trace-kernel/20221207034635.2253990-1-zhengyejian1@huawei.com
+
+Cc: <mhiramat@kernel.org>
+Cc: <zanussi@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: c282a386a397 ("tracing: Add 'onmatch' hist trigger action support")
+Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace_events_hist.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/kernel/trace/trace_events_hist.c
++++ b/kernel/trace/trace_events_hist.c
+@@ -3190,6 +3190,7 @@ static int parse_action_params(struct tr
+ while (params) {
+ if (data->n_params >= SYNTH_FIELDS_MAX) {
+ hist_err(tr, HIST_ERR_TOO_MANY_PARAMS, 0);
++ ret = -EINVAL;
+ goto out;
+ }
+
--- /dev/null
+From 575b76cb885532aae13a9d979fd476bb2b156cb9 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Tue, 22 Nov 2022 12:23:45 -0500
+Subject: tracing/probes: Handle system names with hyphens
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+commit 575b76cb885532aae13a9d979fd476bb2b156cb9 upstream.
+
+When creating probe names, a check is done to make sure it matches basic C
+standard variable naming standards. Basically, starts with alphabetic or
+underline, and then the rest of the characters have alpha-numeric or
+underline in them.
+
+But system names do not have any true naming conventions, as they are
+created by the TRACE_SYSTEM macro and nothing tests to see what they are.
+The "xhci-hcd" trace events has a '-' in the system name. When trying to
+attach a eprobe to one of these trace points, it fails because the system
+name does not follow the variable naming convention because of the
+hyphen, and the eprobe checks fail on this.
+
+Allow hyphens in the system name so that eprobes can attach to the
+"xhci-hcd" trace events.
+
+Link: https://lore.kernel.org/all/Y3eJ8GiGnEvVd8%2FN@macondo/
+Link: https://lore.kernel.org/linux-trace-kernel/20221122122345.160f5077@gandalf.local.home
+
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: stable@vger.kernel.org
+Fixes: 5b7a96220900e ("tracing/probe: Check event/group naming rule at parsing")
+Reported-by: Rafael Mendonca <rafaelmendsr@gmail.com>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.h | 19 ++++++++++++++++---
+ kernel/trace/trace_probe.c | 2 +-
+ 2 files changed, 17 insertions(+), 4 deletions(-)
+
+--- a/kernel/trace/trace.h
++++ b/kernel/trace/trace.h
+@@ -1939,17 +1939,30 @@ static __always_inline void trace_iterat
+ }
+
+ /* Check the name is good for event/group/fields */
+-static inline bool is_good_name(const char *name)
++static inline bool __is_good_name(const char *name, bool hash_ok)
+ {
+- if (!isalpha(*name) && *name != '_')
++ if (!isalpha(*name) && *name != '_' && (!hash_ok || *name != '-'))
+ return false;
+ while (*++name != '\0') {
+- if (!isalpha(*name) && !isdigit(*name) && *name != '_')
++ if (!isalpha(*name) && !isdigit(*name) && *name != '_' &&
++ (!hash_ok || *name != '-'))
+ return false;
+ }
+ return true;
+ }
+
++/* Check the name is good for event/group/fields */
++static inline bool is_good_name(const char *name)
++{
++ return __is_good_name(name, false);
++}
++
++/* Check the name is good for system */
++static inline bool is_good_system_name(const char *name)
++{
++ return __is_good_name(name, true);
++}
++
+ /* Convert certain expected symbols into '_' when generating event names */
+ static inline void sanitize_event_name(char *name)
+ {
+--- a/kernel/trace/trace_probe.c
++++ b/kernel/trace/trace_probe.c
+@@ -246,7 +246,7 @@ int traceprobe_parse_event_name(const ch
+ return -EINVAL;
+ }
+ strlcpy(buf, event, slash - event + 1);
+- if (!is_good_name(buf)) {
++ if (!is_good_system_name(buf)) {
+ trace_probe_log_err(offset, BAD_GROUP_NAME);
+ return -EINVAL;
+ }
--- /dev/null
+From 1993bf97992df2d560287f3c4120eda57426843d Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 19 Dec 2022 23:35:10 +0900
+Subject: x86/kprobes: Fix kprobes instruction boudary check with CONFIG_RETHUNK
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 1993bf97992df2d560287f3c4120eda57426843d upstream.
+
+Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping
+speculative execution after RET instruction, kprobes always failes to
+check the probed instruction boundary by decoding the function body if
+the probed address is after such sequence. (Note that some conditional
+code blocks will be placed after function return, if compiler decides
+it is not on the hot path.)
+
+This is because kprobes expects kgdb puts the INT3 as a software
+breakpoint and it will replace the original instruction.
+But these INT3 are not such purpose, it doesn't need to recover the
+original instruction.
+
+To avoid this issue, kprobes checks whether the INT3 is owned by
+kgdb or not, and if so, stop decoding and make it fail. The other
+INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be
+treated as a one-byte instruction.
+
+Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation")
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/167146051026.1374301.392728975473572291.stgit@devnote3
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/core.c | 10 +++++++---
+ 1 file changed, 7 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/kprobes/core.c
++++ b/arch/x86/kernel/kprobes/core.c
+@@ -37,6 +37,7 @@
+ #include <linux/extable.h>
+ #include <linux/kdebug.h>
+ #include <linux/kallsyms.h>
++#include <linux/kgdb.h>
+ #include <linux/ftrace.h>
+ #include <linux/kasan.h>
+ #include <linux/moduleloader.h>
+@@ -289,12 +290,15 @@ static int can_probe(unsigned long paddr
+ if (ret < 0)
+ return 0;
+
++#ifdef CONFIG_KGDB
+ /*
+- * Another debugging subsystem might insert this breakpoint.
+- * In that case, we can't recover it.
++ * If there is a dynamically installed kgdb sw breakpoint,
++ * this function should not be probed.
+ */
+- if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
++ if (insn.opcode.bytes[0] == INT3_INSN_OPCODE &&
++ kgdb_has_hit_break(addr))
+ return 0;
++#endif
+ addr += insn.length;
+ }
+
--- /dev/null
+From 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 Mon Sep 17 00:00:00 2001
+From: "Masami Hiramatsu (Google)" <mhiramat@kernel.org>
+Date: Mon, 19 Dec 2022 23:35:19 +0900
+Subject: x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK
+
+From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+
+commit 63dc6325ff41ee9e570bde705ac34a39c5dbeb44 upstream.
+
+Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping
+speculative execution after function return, kprobe jump optimization
+always fails on the functions with such INT3 inside the function body.
+(It already checks the INT3 padding between functions, but not inside
+ the function)
+
+To avoid this issue, as same as kprobes, check whether the INT3 comes
+from kgdb or not, and if so, stop decoding and make it fail. The other
+INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be
+treated as a one-byte instruction.
+
+Fixes: e463a09af2f0 ("x86: Add straight-line-speculation mitigation")
+Suggested-by: Peter Zijlstra <peterz@infradead.org>
+Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/167146051929.1374301.7419382929328081706.stgit@devnote3
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/kprobes/opt.c | 28 ++++++++--------------------
+ 1 file changed, 8 insertions(+), 20 deletions(-)
+
+--- a/arch/x86/kernel/kprobes/opt.c
++++ b/arch/x86/kernel/kprobes/opt.c
+@@ -15,6 +15,7 @@
+ #include <linux/extable.h>
+ #include <linux/kdebug.h>
+ #include <linux/kallsyms.h>
++#include <linux/kgdb.h>
+ #include <linux/ftrace.h>
+ #include <linux/objtool.h>
+ #include <linux/pgtable.h>
+@@ -272,19 +273,6 @@ static int insn_is_indirect_jump(struct
+ return ret;
+ }
+
+-static bool is_padding_int3(unsigned long addr, unsigned long eaddr)
+-{
+- unsigned char ops;
+-
+- for (; addr < eaddr; addr++) {
+- if (get_kernel_nofault(ops, (void *)addr) < 0 ||
+- ops != INT3_INSN_OPCODE)
+- return false;
+- }
+-
+- return true;
+-}
+-
+ /* Decode whole function to ensure any instructions don't jump into target */
+ static int can_optimize(unsigned long paddr)
+ {
+@@ -327,15 +315,15 @@ static int can_optimize(unsigned long pa
+ ret = insn_decode_kernel(&insn, (void *)recovered_insn);
+ if (ret < 0)
+ return 0;
+-
++#ifdef CONFIG_KGDB
+ /*
+- * In the case of detecting unknown breakpoint, this could be
+- * a padding INT3 between functions. Let's check that all the
+- * rest of the bytes are also INT3.
++ * If there is a dynamically installed kgdb sw breakpoint,
++ * this function should not be probed.
+ */
+- if (insn.opcode.bytes[0] == INT3_INSN_OPCODE)
+- return is_padding_int3(addr, paddr - offset + size) ? 1 : 0;
+-
++ if (insn.opcode.bytes[0] == INT3_INSN_OPCODE &&
++ kgdb_has_hit_break(addr))
++ return 0;
++#endif
+ /* Recover address */
+ insn.kaddr = (void *)addr;
+ insn.next_byte = (void *)(addr + insn.length);
--- /dev/null
+From be1b670f61443aa5d0d01782e9b8ea0ee825d018 Mon Sep 17 00:00:00 2001
+From: Ashok Raj <ashok.raj@intel.com>
+Date: Tue, 29 Nov 2022 13:08:27 -0800
+Subject: x86/microcode/intel: Do not retry microcode reloading on the APs
+
+From: Ashok Raj <ashok.raj@intel.com>
+
+commit be1b670f61443aa5d0d01782e9b8ea0ee825d018 upstream.
+
+The retries in load_ucode_intel_ap() were in place to support systems
+with mixed steppings. Mixed steppings are no longer supported and there is
+only one microcode image at a time. Any retries will simply reattempt to
+apply the same image over and over without making progress.
+
+ [ bp: Zap the circumstantial reasoning from the commit message. ]
+
+Fixes: 06b8534cb728 ("x86/microcode: Rework microcode loading")
+Signed-off-by: Ashok Raj <ashok.raj@intel.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: stable@vger.kernel.org
+Link: https://lore.kernel.org/r/20221129210832.107850-3-ashok.raj@intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/cpu/microcode/intel.c | 8 +-------
+ 1 file changed, 1 insertion(+), 7 deletions(-)
+
+--- a/arch/x86/kernel/cpu/microcode/intel.c
++++ b/arch/x86/kernel/cpu/microcode/intel.c
+@@ -659,7 +659,6 @@ void load_ucode_intel_ap(void)
+ else
+ iup = &intel_ucode_patch;
+
+-reget:
+ if (!*iup) {
+ patch = __load_ucode_intel(&uci);
+ if (!patch)
+@@ -670,12 +669,7 @@ reget:
+
+ uci.mc = *iup;
+
+- if (apply_microcode_early(&uci, true)) {
+- /* Mixed-silicon system? Try to refetch the proper patch: */
+- *iup = NULL;
+-
+- goto reget;
+- }
++ apply_microcode_early(&uci, true);
+ }
+
+ static struct microcode_intel *find_patch(struct ucode_cpu_info *uci)
projects / thirdparty / kernel / stable-queue.git / commitdiff
