--- /dev/null
+From 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c Mon Sep 17 00:00:00 2001
+From: D Scott Phillips <scott@os.amperecomputing.com>
+Date: Mon, 20 Dec 2021 15:41:14 -0800
+Subject: arm64: errata: Fix exec handling in erratum 1418040 workaround
+
+From: D Scott Phillips <scott@os.amperecomputing.com>
+
+commit 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c upstream.
+
+The erratum 1418040 workaround enables CNTVCT_EL1 access trapping in EL0
+when executing compat threads. The workaround is applied when switching
+between tasks, but the need for the workaround could also change at an
+exec(), when a non-compat task execs a compat binary or vice versa. Apply
+the workaround in arch_setup_new_exec().
+
+This leaves a small window of time between SET_PERSONALITY and
+arch_setup_new_exec where preemption could occur and confuse the old
+workaround logic that compares TIF_32BIT between prev and next. Instead, we
+can just read cntkctl to make sure it's in the state that the next task
+needs. I measured cntkctl read time to be about the same as a mov from a
+general-purpose register on N1. Update the workaround logic to examine the
+current value of cntkctl instead of the previous task's compat state.
+
+Fixes: d49f7d7376d0 ("arm64: Move handling of erratum 1418040 into C code")
+Cc: <stable@vger.kernel.org> # 5.9.x
+Signed-off-by: D Scott Phillips <scott@os.amperecomputing.com>
+Reviewed-by: Marc Zyngier <maz@kernel.org>
+Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomputing.com
+Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/kernel/process.c | 39 ++++++++++++++++-----------------------
+ 1 file changed, 16 insertions(+), 23 deletions(-)
+
+--- a/arch/arm64/kernel/process.c
++++ b/arch/arm64/kernel/process.c
+@@ -511,34 +511,26 @@ static void entry_task_switch(struct tas
+
+ /*
+ * ARM erratum 1418040 handling, affecting the 32bit view of CNTVCT.
+- * Assuming the virtual counter is enabled at the beginning of times:
+- *
+- * - disable access when switching from a 64bit task to a 32bit task
+- * - enable access when switching from a 32bit task to a 64bit task
++ * Ensure access is disabled when switching to a 32bit task, ensure
++ * access is enabled when switching to a 64bit task.
+ */
+-static void erratum_1418040_thread_switch(struct task_struct *prev,
+- struct task_struct *next)
++static void erratum_1418040_thread_switch(struct task_struct *next)
+ {
+- bool prev32, next32;
+- u64 val;
+-
+- if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040))
+- return;
+-
+- prev32 = is_compat_thread(task_thread_info(prev));
+- next32 = is_compat_thread(task_thread_info(next));
+-
+- if (prev32 == next32 || !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
++ if (!IS_ENABLED(CONFIG_ARM64_ERRATUM_1418040) ||
++ !this_cpu_has_cap(ARM64_WORKAROUND_1418040))
+ return;
+
+- val = read_sysreg(cntkctl_el1);
+-
+- if (!next32)
+- val |= ARCH_TIMER_USR_VCT_ACCESS_EN;
++ if (is_compat_thread(task_thread_info(next)))
++ sysreg_clear_set(cntkctl_el1, ARCH_TIMER_USR_VCT_ACCESS_EN, 0);
+ else
+- val &= ~ARCH_TIMER_USR_VCT_ACCESS_EN;
++ sysreg_clear_set(cntkctl_el1, 0, ARCH_TIMER_USR_VCT_ACCESS_EN);
++}
+
+- write_sysreg(val, cntkctl_el1);
++static void erratum_1418040_new_exec(void)
++{
++ preempt_disable();
++ erratum_1418040_thread_switch(current);
++ preempt_enable();
+ }
+
+ /*
+@@ -556,7 +548,7 @@ __notrace_funcgraph struct task_struct *
+ entry_task_switch(next);
+ uao_thread_switch(next);
+ ssbs_thread_switch(next);
+- erratum_1418040_thread_switch(prev, next);
++ erratum_1418040_thread_switch(next);
+
+ /*
+ * Complete any pending TLB or cache maintenance on this CPU in case
+@@ -622,6 +614,7 @@ void arch_setup_new_exec(void)
+ current->mm->context.flags = is_compat_task() ? MMCF_AARCH32 : 0;
+
+ ptrauth_thread_init_user(current);
++ erratum_1418040_new_exec();
+
+ if (task_spec_ssb_noexec(current)) {
+ arch_prctl_spec_ctrl_set(current, PR_SPEC_STORE_BYPASS,
--- /dev/null
+From 932a9b5870d38b87ba0a9923c804b1af7d3605b9 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@kernel.org>
+Date: Tue, 25 Jan 2022 15:39:16 -0500
+Subject: ceph: properly put ceph_string reference after async create attempt
+
+From: Jeff Layton <jlayton@kernel.org>
+
+commit 932a9b5870d38b87ba0a9923c804b1af7d3605b9 upstream.
+
+The reference acquired by try_prep_async_create is currently leaked.
+Ensure we put it.
+
+Cc: stable@vger.kernel.org
+Fixes: 9a8d03ca2e2c ("ceph: attempt to do async create when possible")
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/file.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/fs/ceph/file.c
++++ b/fs/ceph/file.c
+@@ -743,8 +743,10 @@ retry:
+ restore_deleg_ino(dir, req->r_deleg_ino);
+ ceph_mdsc_put_request(req);
+ try_async = false;
++ ceph_put_string(rcu_dereference_raw(lo.pool_ns));
+ goto retry;
+ }
++ ceph_put_string(rcu_dereference_raw(lo.pool_ns));
+ goto out_req;
+ }
+ }
--- /dev/null
+From 4584a768f22b7669cdebabc911543621ac661341 Mon Sep 17 00:00:00 2001
+From: Jeff Layton <jlayton@kernel.org>
+Date: Wed, 26 Jan 2022 12:36:49 -0500
+Subject: ceph: set pool_ns in new inode layout for async creates
+
+From: Jeff Layton <jlayton@kernel.org>
+
+commit 4584a768f22b7669cdebabc911543621ac661341 upstream.
+
+Dan reported that he was unable to write to files that had been
+asynchronously created when the client's OSD caps are restricted to a
+particular namespace.
+
+The issue is that the layout for the new inode is only partially being
+filled. Ensure that we populate the pool_ns_data and pool_ns_len in the
+iinfo before calling ceph_fill_inode.
+
+Cc: stable@vger.kernel.org
+URL: https://tracker.ceph.com/issues/54013
+Fixes: 9a8d03ca2e2c ("ceph: attempt to do async create when possible")
+Reported-by: Dan van der Ster <dan@vanderster.com>
+Signed-off-by: Jeff Layton <jlayton@kernel.org>
+Reviewed-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/ceph/file.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/fs/ceph/file.c
++++ b/fs/ceph/file.c
+@@ -577,6 +577,7 @@ static int ceph_finish_async_create(stru
+ struct ceph_inode_info *ci = ceph_inode(dir);
+ struct inode *inode;
+ struct timespec64 now;
++ struct ceph_string *pool_ns;
+ struct ceph_mds_client *mdsc = ceph_sb_to_mdsc(dir->i_sb);
+ struct ceph_vino vino = { .ino = req->r_deleg_ino,
+ .snap = CEPH_NOSNAP };
+@@ -626,6 +627,12 @@ static int ceph_finish_async_create(stru
+ in.max_size = cpu_to_le64(lo->stripe_unit);
+
+ ceph_file_layout_to_legacy(lo, &in.layout);
++ /* lo is private, so pool_ns can't change */
++ pool_ns = rcu_dereference_raw(lo->pool_ns);
++ if (pool_ns) {
++ iinfo.pool_ns_len = pool_ns->len;
++ iinfo.pool_ns_data = pool_ns->str;
++ }
+
+ down_read(&mdsc->snap_rwsem);
+ ret = ceph_fill_inode(inode, NULL, &iinfo, NULL, req->r_session,
--- /dev/null
+From e3d26528e083e612314d4dcd713f3d5a26143ddc Mon Sep 17 00:00:00 2001
+From: Lucas Stach <l.stach@pengutronix.de>
+Date: Thu, 6 Jan 2022 19:10:21 +0100
+Subject: drm/etnaviv: relax submit size limits
+
+From: Lucas Stach <l.stach@pengutronix.de>
+
+commit e3d26528e083e612314d4dcd713f3d5a26143ddc upstream.
+
+While all userspace tried to limit commandstreams to 64K in size,
+a bug in the Mesa driver lead to command streams of up to 128K
+being submitted. Allow those to avoid breaking existing userspace.
+
+Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes")
+Cc: stable@vger.kernel.org
+Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
+Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
++++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c
+@@ -469,8 +469,8 @@ int etnaviv_ioctl_gem_submit(struct drm_
+ return -EINVAL;
+ }
+
+- if (args->stream_size > SZ_64K || args->nr_relocs > SZ_64K ||
+- args->nr_bos > SZ_64K || args->nr_pmrs > 128) {
++ if (args->stream_size > SZ_128K || args->nr_relocs > SZ_128K ||
++ args->nr_bos > SZ_128K || args->nr_pmrs > 128) {
+ DRM_ERROR("submit arguments out of size limits\n");
+ return -EINVAL;
+ }
--- /dev/null
+From f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 Mon Sep 17 00:00:00 2001
+From: Ard Biesheuvel <ardb@kernel.org>
+Date: Wed, 12 Jan 2022 11:14:13 +0100
+Subject: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines
+
+From: Ard Biesheuvel <ardb@kernel.org>
+
+commit f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 upstream.
+
+Aditya reports [0] that his recent MacbookPro crashes in the firmware
+when using the variable services at runtime. The culprit appears to be a
+call to QueryVariableInfo(), which we did not use to call on Apple x86
+machines in the past as they only upgraded from EFI v1.10 to EFI v2.40
+firmware fairly recently, and QueryVariableInfo() (along with
+UpdateCapsule() et al) was added in EFI v2.00.
+
+The only runtime service introduced in EFI v2.00 that we actually use in
+Linux is QueryVariableInfo(), as the capsule based ones are optional,
+generally not used at runtime (all the LVFS/fwupd firmware update
+infrastructure uses helper EFI programs that invoke capsule update at
+boot time, not runtime), and not implemented by Apple machines in the
+first place. QueryVariableInfo() is used to 'safely' set variables,
+i.e., only when there is enough space. This prevents machines with buggy
+firmwares from corrupting their NVRAMs when they run out of space.
+
+Given that Apple machines have been using EFI v1.10 services only for
+the longest time (the EFI v2.0 spec was released in 2006, and Linux
+support for the newly introduced runtime services was added in 2011, but
+the MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),
+let's avoid the EFI v2.0 ones on all Apple x86 machines.
+
+[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/
+
+Cc: <stable@vger.kernel.org>
+Cc: Jeremy Kerr <jk@ozlabs.org>
+Cc: Matthew Garrett <mjg59@srcf.ucam.org>
+Reported-by: Aditya Garg <gargaditya08@live.com>
+Tested-by: Orlando Chamberlain <redecorating@protonmail.com>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Tested-by: Aditya Garg <gargaditya08@live.com>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=215277
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/efi/efi.c | 7 +++++++
+ 1 file changed, 7 insertions(+)
+
+--- a/drivers/firmware/efi/efi.c
++++ b/drivers/firmware/efi/efi.c
+@@ -719,6 +719,13 @@ void __init efi_systab_report_header(con
+ systab_hdr->revision >> 16,
+ systab_hdr->revision & 0xffff,
+ vendor);
++
++ if (IS_ENABLED(CONFIG_X86_64) &&
++ systab_hdr->revision > EFI_1_10_SYSTEM_TABLE_REVISION &&
++ !strcmp(vendor, "Apple")) {
++ pr_info("Apple Mac detected, using EFI v1.10 runtime services only\n");
++ efi.runtime_version = EFI_1_10_SYSTEM_TABLE_REVISION;
++ }
+ }
+
+ static __initdata char memory_type_name[][13] = {
--- /dev/null
+From 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 Mon Sep 17 00:00:00 2001
+From: Amir Goldstein <amir73il@gmail.com>
+Date: Thu, 20 Jan 2022 23:53:05 +0200
+Subject: fsnotify: fix fsnotify hooks in pseudo filesystems
+
+From: Amir Goldstein <amir73il@gmail.com>
+
+commit 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 upstream.
+
+Commit 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of
+d_delete()") moved the fsnotify delete hook before d_delete() so fsnotify
+will have access to a positive dentry.
+
+This allowed a race where opening the deleted file via cached dentry
+is now possible after receiving the IN_DELETE event.
+
+To fix the regression in pseudo filesystems, convert d_delete() calls
+to d_drop() (see commit 46c46f8df9aa ("devpts_pty_kill(): don't bother
+with d_delete()") and move the fsnotify hook after d_drop().
+
+Add a missing fsnotify_unlink() hook in nfsdfs that was found during
+the audit of fsnotify hooks in pseudo filesystems.
+
+Note that the fsnotify hooks in simple_recursive_removal() follow
+d_invalidate(), so they require no change.
+
+Link: https://lore.kernel.org/r/20220120215305.282577-2-amir73il@gmail.com
+Reported-by: Ivan Delalande <colona@arista.com>
+Link: https://lore.kernel.org/linux-fsdevel/YeNyzoDM5hP5LtGW@visor/
+Fixes: 49246466a989 ("fsnotify: move fsnotify_nameremove() hook out of d_delete()")
+Cc: stable@vger.kernel.org # v5.3+
+Signed-off-by: Amir Goldstein <amir73il@gmail.com>
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/configfs/dir.c | 6 +++---
+ fs/devpts/inode.c | 2 +-
+ fs/nfsd/nfsctl.c | 5 +++--
+ net/sunrpc/rpc_pipe.c | 4 ++--
+ 4 files changed, 9 insertions(+), 8 deletions(-)
+
+--- a/fs/configfs/dir.c
++++ b/fs/configfs/dir.c
+@@ -1805,8 +1805,8 @@ void configfs_unregister_group(struct co
+ configfs_detach_group(&group->cg_item);
+ d_inode(dentry)->i_flags |= S_DEAD;
+ dont_mount(dentry);
++ d_drop(dentry);
+ fsnotify_rmdir(d_inode(parent), dentry);
+- d_delete(dentry);
+ inode_unlock(d_inode(parent));
+
+ dput(dentry);
+@@ -1947,10 +1947,10 @@ void configfs_unregister_subsystem(struc
+ configfs_detach_group(&group->cg_item);
+ d_inode(dentry)->i_flags |= S_DEAD;
+ dont_mount(dentry);
+- fsnotify_rmdir(d_inode(root), dentry);
+ inode_unlock(d_inode(dentry));
+
+- d_delete(dentry);
++ d_drop(dentry);
++ fsnotify_rmdir(d_inode(root), dentry);
+
+ inode_unlock(d_inode(root));
+
+--- a/fs/devpts/inode.c
++++ b/fs/devpts/inode.c
+@@ -621,8 +621,8 @@ void devpts_pty_kill(struct dentry *dent
+
+ dentry->d_fsdata = NULL;
+ drop_nlink(dentry->d_inode);
+- fsnotify_unlink(d_inode(dentry->d_parent), dentry);
+ d_drop(dentry);
++ fsnotify_unlink(d_inode(dentry->d_parent), dentry);
+ dput(dentry); /* d_alloc_name() in devpts_pty_new() */
+ }
+
+--- a/fs/nfsd/nfsctl.c
++++ b/fs/nfsd/nfsctl.c
+@@ -1247,7 +1247,8 @@ static void nfsdfs_remove_file(struct in
+ clear_ncl(d_inode(dentry));
+ dget(dentry);
+ ret = simple_unlink(dir, dentry);
+- d_delete(dentry);
++ d_drop(dentry);
++ fsnotify_unlink(dir, dentry);
+ dput(dentry);
+ WARN_ON_ONCE(ret);
+ }
+@@ -1336,8 +1337,8 @@ void nfsd_client_rmdir(struct dentry *de
+ dget(dentry);
+ ret = simple_rmdir(dir, dentry);
+ WARN_ON_ONCE(ret);
++ d_drop(dentry);
+ fsnotify_rmdir(dir, dentry);
+- d_delete(dentry);
+ dput(dentry);
+ inode_unlock(dir);
+ }
+--- a/net/sunrpc/rpc_pipe.c
++++ b/net/sunrpc/rpc_pipe.c
+@@ -599,9 +599,9 @@ static int __rpc_rmdir(struct inode *dir
+
+ dget(dentry);
+ ret = simple_rmdir(dir, dentry);
++ d_drop(dentry);
+ if (!ret)
+ fsnotify_rmdir(dir, dentry);
+- d_delete(dentry);
+ dput(dentry);
+ return ret;
+ }
+@@ -612,9 +612,9 @@ static int __rpc_unlink(struct inode *di
+
+ dget(dentry);
+ ret = simple_unlink(dir, dentry);
++ d_drop(dentry);
+ if (!ret)
+ fsnotify_unlink(dir, dentry);
+- d_delete(dentry);
+ dput(dentry);
+ return ret;
+ }
--- /dev/null
+From 4c282e51e4450b94680d6ca3b10f830483b1f243 Mon Sep 17 00:00:00 2001
+From: Like Xu <likexu@tencent.com>
+Date: Wed, 26 Jan 2022 17:22:25 +0000
+Subject: KVM: x86: Update vCPU's runtime CPUID on write to MSR_IA32_XSS
+
+From: Like Xu <likexu@tencent.com>
+
+commit 4c282e51e4450b94680d6ca3b10f830483b1f243 upstream.
+
+Do a runtime CPUID update for a vCPU if MSR_IA32_XSS is written, as the
+size in bytes of the XSAVE area is affected by the states enabled in XSS.
+
+Fixes: 203000993de5 ("kvm: vmx: add MSR logic for XSAVES")
+Cc: stable@vger.kernel.org
+Signed-off-by: Like Xu <likexu@tencent.com>
+[sean: split out as a separate patch, adjust Fixes tag]
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Message-Id: <20220126172226.2298529-3-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/x86.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -3171,6 +3171,7 @@ int kvm_set_msr_common(struct kvm_vcpu *
+ if (data & ~supported_xss)
+ return 1;
+ vcpu->arch.ia32_xss = data;
++ kvm_update_cpuid_runtime(vcpu);
+ break;
+ case MSR_SMI_COUNT:
+ if (!msr_info->host_initiated)
--- /dev/null
+From 4e1860a3863707e8177329c006d10f9e37e097a8 Mon Sep 17 00:00:00 2001
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+Date: Wed, 5 Jan 2022 16:09:57 +0100
+Subject: netfilter: nft_payload: do not update layer 4 checksum when mangling fragments
+
+From: Pablo Neira Ayuso <pablo@netfilter.org>
+
+commit 4e1860a3863707e8177329c006d10f9e37e097a8 upstream.
+
+IP fragments do not come with the transport header, hence skip bogus
+layer 4 checksum updates.
+
+Fixes: 1814096980bb ("netfilter: nft_payload: layer 4 checksum adjustment for pseudoheader fields")
+Reported-and-tested-by: Steffen Weinreich <steve@weinreich.org>
+Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
+Signed-off-by: Florian Westphal <fw@strlen.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/netfilter/nft_payload.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/net/netfilter/nft_payload.c
++++ b/net/netfilter/nft_payload.c
+@@ -502,6 +502,9 @@ static int nft_payload_l4csum_offset(con
+ struct sk_buff *skb,
+ unsigned int *l4csum_offset)
+ {
++ if (pkt->xt.fragoff)
++ return -1;
++
+ switch (pkt->tprot) {
+ case IPPROTO_TCP:
+ *l4csum_offset = offsetof(struct tcphdr, check);
--- /dev/null
+From 96fd2e89fba1aaada6f4b1e5d25a9d9ecbe1943d Mon Sep 17 00:00:00 2001
+From: Zhengjun Xing <zhengjun.xing@linux.intel.com>
+Date: Thu, 23 Dec 2021 22:48:26 +0800
+Subject: perf/x86/intel/uncore: Fix CAS_COUNT_WRITE issue for ICX
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Zhengjun Xing <zhengjun.xing@linux.intel.com>
+
+commit 96fd2e89fba1aaada6f4b1e5d25a9d9ecbe1943d upstream.
+
+The user recently report a perf issue in the ICX platform, when test by
+perf event “uncore_imc_x/cas_count_write”,the write bandwidth is always
+very small (only 0.38MB/s), it is caused by the wrong "umask" for the
+"cas_count_write" event. When double-checking, find "cas_count_read"
+also is wrong.
+
+The public document for ICX uncore:
+
+3rd Gen Intel® Xeon® Processor Scalable Family, Codename Ice Lake,Uncore
+Performance Monitoring Reference Manual, Revision 1.00, May 2021
+
+On 2.4.7, it defines Unit Masks for CAS_COUNT:
+RD b00001111
+WR b00110000
+
+So corrected both "cas_count_read" and "cas_count_write" for ICX.
+
+Old settings:
+ hswep_uncore_imc_events
+ INTEL_UNCORE_EVENT_DESC(cas_count_read, "event=0x04,umask=0x03")
+ INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x0c")
+
+New settings:
+ snr_uncore_imc_events
+ INTEL_UNCORE_EVENT_DESC(cas_count_read, "event=0x04,umask=0x0f")
+ INTEL_UNCORE_EVENT_DESC(cas_count_write, "event=0x04,umask=0x30")
+
+Fixes: 2b3b76b5ec67 ("perf/x86/intel/uncore: Add Ice Lake server uncore support")
+Signed-off-by: Zhengjun Xing <zhengjun.xing@linux.intel.com>
+Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
+Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
+Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
+Cc: stable@vger.kernel.org
+Link: https://lkml.kernel.org/r/20211223144826.841267-1-zhengjun.xing@linux.intel.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/events/intel/uncore_snbep.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/events/intel/uncore_snbep.c
++++ b/arch/x86/events/intel/uncore_snbep.c
+@@ -5239,7 +5239,7 @@ static struct intel_uncore_type icx_unco
+ .fixed_ctr_bits = 48,
+ .fixed_ctr = SNR_IMC_MMIO_PMON_FIXED_CTR,
+ .fixed_ctl = SNR_IMC_MMIO_PMON_FIXED_CTL,
+- .event_descs = hswep_uncore_imc_events,
++ .event_descs = snr_uncore_imc_events,
+ .perf_ctr = SNR_IMC_MMIO_PMON_CTR0,
+ .event_ctl = SNR_IMC_MMIO_PMON_CTL0,
+ .event_mask = SNBEP_PMON_RAW_EVENT_MASK,
--- /dev/null
+From c9d967b2ce40d71e968eb839f36c936b8a9cf1ea Mon Sep 17 00:00:00 2001
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Date: Thu, 13 Jan 2022 19:44:20 +0100
+Subject: PM: wakeup: simplify the output logic of pm_show_wakelocks()
+
+From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+commit c9d967b2ce40d71e968eb839f36c936b8a9cf1ea upstream.
+
+The buffer handling in pm_show_wakelocks() is tricky, and hopefully
+correct. Ensure it really is correct by using sysfs_emit_at() which
+handles all of the tricky string handling logic in a PAGE_SIZE buffer
+for us automatically as this is a sysfs file being read from.
+
+Reviewed-by: Lee Jones <lee.jones@linaro.org>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/power/wakelock.c | 11 ++++-------
+ 1 file changed, 4 insertions(+), 7 deletions(-)
+
+--- a/kernel/power/wakelock.c
++++ b/kernel/power/wakelock.c
+@@ -39,23 +39,20 @@ ssize_t pm_show_wakelocks(char *buf, boo
+ {
+ struct rb_node *node;
+ struct wakelock *wl;
+- char *str = buf;
+- char *end = buf + PAGE_SIZE;
++ int len = 0;
+
+ mutex_lock(&wakelocks_lock);
+
+ for (node = rb_first(&wakelocks_tree); node; node = rb_next(node)) {
+ wl = rb_entry(node, struct wakelock, node);
+ if (wl->ws->active == show_active)
+- str += scnprintf(str, end - str, "%s ", wl->name);
++ len += sysfs_emit_at(buf, len, "%s ", wl->name);
+ }
+- if (str > buf)
+- str--;
+
+- str += scnprintf(str, end - str, "\n");
++ len += sysfs_emit_at(buf, len, "\n");
+
+ mutex_unlock(&wakelocks_lock);
+- return (str - buf);
++ return len;
+ }
+
+ #if CONFIG_PM_WAKELOCKS_LIMIT > 0
--- /dev/null
+From 31c25585695abdf03d6160aa6d829e855b256329 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Thu, 20 Jan 2022 01:07:12 +0000
+Subject: Revert "KVM: SVM: avoid infinite loop on NPF from bad address"
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit 31c25585695abdf03d6160aa6d829e855b256329 upstream.
+
+Revert a completely broken check on an "invalid" RIP in SVM's workaround
+for the DecodeAssists SMAP errata. kvm_vcpu_gfn_to_memslot() obviously
+expects a gfn, i.e. operates in the guest physical address space, whereas
+RIP is a virtual (not even linear) address. The "fix" worked for the
+problematic KVM selftest because the test identity mapped RIP.
+
+Fully revert the hack instead of trying to translate RIP to a GPA, as the
+non-SEV case is now handled earlier, and KVM cannot access guest page
+tables to translate RIP.
+
+This reverts commit e72436bc3a5206f95bb384e741154166ddb3202e.
+
+Fixes: e72436bc3a52 ("KVM: SVM: avoid infinite loop on NPF from bad address")
+Reported-by: Liam Merwick <liam.merwick@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
+Message-Id: <20220120010719.711476-3-seanjc@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kvm/svm/svm.c | 7 -------
+ virt/kvm/kvm_main.c | 1 -
+ 2 files changed, 8 deletions(-)
+
+--- a/arch/x86/kvm/svm/svm.c
++++ b/arch/x86/kvm/svm/svm.c
+@@ -4146,13 +4146,6 @@ static bool svm_can_emulate_instruction(
+ if (likely(!insn || insn_len))
+ return true;
+
+- /*
+- * If RIP is invalid, go ahead with emulation which will cause an
+- * internal error exit.
+- */
+- if (!kvm_vcpu_gfn_to_memslot(vcpu, kvm_rip_read(vcpu) >> PAGE_SHIFT))
+- return true;
+-
+ cr4 = kvm_read_cr4(vcpu);
+ smep = cr4 & X86_CR4_SMEP;
+ smap = cr4 & X86_CR4_SMAP;
+--- a/virt/kvm/kvm_main.c
++++ b/virt/kvm/kvm_main.c
+@@ -1691,7 +1691,6 @@ struct kvm_memory_slot *kvm_vcpu_gfn_to_
+ {
+ return __gfn_to_memslot(kvm_vcpu_memslots(vcpu), gfn);
+ }
+-EXPORT_SYMBOL_GPL(kvm_vcpu_gfn_to_memslot);
+
+ bool kvm_is_visible_gfn(struct kvm *kvm, gfn_t gfn)
+ {
scsi-zfcp-fix-failed-recovery-on-gone-remote-port-with-non-npiv-fcp-devices.patch
udf-restore-i_lenalloc-when-inode-expansion-fails.patch
udf-fix-null-ptr-deref-when-converting-from-inline-format.patch
+efi-runtime-avoid-efiv2-runtime-services-on-apple-x86-machines.patch
+pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch
+tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch
+tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch
+ceph-properly-put-ceph_string-reference-after-async-create-attempt.patch
+ceph-set-pool_ns-in-new-inode-layout-for-async-creates.patch
+fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch
+revert-kvm-svm-avoid-infinite-loop-on-npf-from-bad-address.patch
+perf-x86-intel-uncore-fix-cas_count_write-issue-for-icx.patch
+drm-etnaviv-relax-submit-size-limits.patch
+kvm-x86-update-vcpu-s-runtime-cpuid-on-write-to-msr_ia32_xss.patch
+arm64-errata-fix-exec-handling-in-erratum-1418040-workaround.patch
+netfilter-nft_payload-do-not-update-layer-4-checksum-when-mangling-fragments.patch
--- /dev/null
+From 67ab5eb71b37b55f7c5522d080a1b42823351776 Mon Sep 17 00:00:00 2001
+From: Tom Zanussi <zanussi@kernel.org>
+Date: Thu, 27 Jan 2022 15:44:18 -0600
+Subject: tracing: Don't inc err_log entry count if entry allocation fails
+
+From: Tom Zanussi <zanussi@kernel.org>
+
+commit 67ab5eb71b37b55f7c5522d080a1b42823351776 upstream.
+
+tr->n_err_log_entries should only be increased if entry allocation
+succeeds.
+
+Doing it when it fails won't cause any problems other than wasting an
+entry, but should be fixed anyway.
+
+Link: https://lkml.kernel.org/r/cad1ab28f75968db0f466925e7cba5970cec6c29.1643319703.git.zanussi@kernel.org
+
+Cc: stable@vger.kernel.org
+Fixes: 2f754e771b1a6 ("tracing: Don't inc err_log entry count if entry allocation fails")
+Signed-off-by: Tom Zanussi <zanussi@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/trace/trace.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/trace/trace.c
++++ b/kernel/trace/trace.c
+@@ -7257,7 +7257,8 @@ static struct tracing_log_err *get_traci
+ err = kzalloc(sizeof(*err), GFP_KERNEL);
+ if (!err)
+ err = ERR_PTR(-ENOMEM);
+- tr->n_err_log_entries++;
++ else
++ tr->n_err_log_entries++;
+
+ return err;
+ }
--- /dev/null
+From e629e7b525a179e29d53463d992bdee759c950fb Mon Sep 17 00:00:00 2001
+From: Xiaoke Wang <xkernel.wang@foxmail.com>
+Date: Tue, 25 Jan 2022 12:07:15 +0800
+Subject: tracing/histogram: Fix a potential memory leak for kstrdup()
+
+From: Xiaoke Wang <xkernel.wang@foxmail.com>
+
+commit e629e7b525a179e29d53463d992bdee759c950fb upstream.
+
+kfree() is missing on an error path to free the memory allocated by
+kstrdup():
+
+ p = param = kstrdup(data->params[i], GFP_KERNEL);
+
+So it is better to free it via kfree(p).
+
+Link: https://lkml.kernel.org/r/tencent_C52895FD37802832A3E5B272D05008866F0A@qq.com
+
+Cc: stable@vger.kernel.org
+Fixes: d380dcde9a07c ("tracing: Fix now invalid var_ref_vals assumption in trace action")
+Signed-off-by: Xiaoke Wang <xkernel.wang@foxmail.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
+@@ -3506,6 +3506,7 @@ static int trace_action_create(struct hi
+
+ var_ref_idx = find_var_ref_idx(hist_data, var_ref);
+ if (WARN_ON(var_ref_idx < 0)) {
++ kfree(p);
+ ret = var_ref_idx;
+ goto err;
+ }
projects / thirdparty / kernel / stable-queue.git / commitdiff
