From: Greg Kroah-Hartman Date: Sat, 29 Jan 2022 14:48:18 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v5.4.176~83 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b58a9750c1ed99736fe13b906751afa87fbaf864;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: arm64-errata-fix-exec-handling-in-erratum-1418040-workaround.patch ceph-properly-put-ceph_string-reference-after-async-create-attempt.patch ceph-set-pool_ns-in-new-inode-layout-for-async-creates.patch drm-etnaviv-relax-submit-size-limits.patch efi-runtime-avoid-efiv2-runtime-services-on-apple-x86-machines.patch fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch kvm-x86-update-vcpu-s-runtime-cpuid-on-write-to-msr_ia32_xss.patch netfilter-nft_payload-do-not-update-layer-4-checksum-when-mangling-fragments.patch perf-x86-intel-uncore-fix-cas_count_write-issue-for-icx.patch pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch revert-kvm-svm-avoid-infinite-loop-on-npf-from-bad-address.patch tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch --- diff --git a/queue-5.10/arm64-errata-fix-exec-handling-in-erratum-1418040-workaround.patch b/queue-5.10/arm64-errata-fix-exec-handling-in-erratum-1418040-workaround.patch new file mode 100644 index 00000000000..b51e4f97174 --- /dev/null +++ b/queue-5.10/arm64-errata-fix-exec-handling-in-erratum-1418040-workaround.patch @@ -0,0 +1,102 @@ +From 38e0257e0e6f4fef2aa2966b089b56a8b1cfb75c Mon Sep 17 00:00:00 2001 +From: D Scott Phillips +Date: Mon, 20 Dec 2021 15:41:14 -0800 +Subject: arm64: errata: Fix exec handling in erratum 1418040 workaround + +From: D Scott Phillips + +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: # 5.9.x +Signed-off-by: D Scott Phillips +Reviewed-by: Marc Zyngier +Link: https://lore.kernel.org/r/20211220234114.3926-1-scott@os.amperecomputing.com +Signed-off-by: Catalin Marinas +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/ceph-properly-put-ceph_string-reference-after-async-create-attempt.patch b/queue-5.10/ceph-properly-put-ceph_string-reference-after-async-create-attempt.patch new file mode 100644 index 00000000000..660f2dcc317 --- /dev/null +++ b/queue-5.10/ceph-properly-put-ceph_string-reference-after-async-create-attempt.patch @@ -0,0 +1,35 @@ +From 932a9b5870d38b87ba0a9923c804b1af7d3605b9 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Tue, 25 Jan 2022 15:39:16 -0500 +Subject: ceph: properly put ceph_string reference after async create attempt + +From: Jeff Layton + +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 +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } + } diff --git a/queue-5.10/ceph-set-pool_ns-in-new-inode-layout-for-async-creates.patch b/queue-5.10/ceph-set-pool_ns-in-new-inode-layout-for-async-creates.patch new file mode 100644 index 00000000000..3cc5269f108 --- /dev/null +++ b/queue-5.10/ceph-set-pool_ns-in-new-inode-layout-for-async-creates.patch @@ -0,0 +1,52 @@ +From 4584a768f22b7669cdebabc911543621ac661341 Mon Sep 17 00:00:00 2001 +From: Jeff Layton +Date: Wed, 26 Jan 2022 12:36:49 -0500 +Subject: ceph: set pool_ns in new inode layout for async creates + +From: Jeff Layton + +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 +Signed-off-by: Jeff Layton +Reviewed-by: Ilya Dryomov +Signed-off-by: Ilya Dryomov +Signed-off-by: Greg Kroah-Hartman +--- + 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, diff --git a/queue-5.10/drm-etnaviv-relax-submit-size-limits.patch b/queue-5.10/drm-etnaviv-relax-submit-size-limits.patch new file mode 100644 index 00000000000..9ffdb37f766 --- /dev/null +++ b/queue-5.10/drm-etnaviv-relax-submit-size-limits.patch @@ -0,0 +1,35 @@ +From e3d26528e083e612314d4dcd713f3d5a26143ddc Mon Sep 17 00:00:00 2001 +From: Lucas Stach +Date: Thu, 6 Jan 2022 19:10:21 +0100 +Subject: drm/etnaviv: relax submit size limits + +From: Lucas Stach + +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 +Reviewed-by: Christian Gmeiner +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/efi-runtime-avoid-efiv2-runtime-services-on-apple-x86-machines.patch b/queue-5.10/efi-runtime-avoid-efiv2-runtime-services-on-apple-x86-machines.patch new file mode 100644 index 00000000000..e9f5c63a84f --- /dev/null +++ b/queue-5.10/efi-runtime-avoid-efiv2-runtime-services-on-apple-x86-machines.patch @@ -0,0 +1,62 @@ +From f5390cd0b43c2e54c7cf5506c7da4a37c5cef746 Mon Sep 17 00:00:00 2001 +From: Ard Biesheuvel +Date: Wed, 12 Jan 2022 11:14:13 +0100 +Subject: efi: runtime: avoid EFIv2 runtime services on Apple x86 machines + +From: Ard Biesheuvel + +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: +Cc: Jeremy Kerr +Cc: Matthew Garrett +Reported-by: Aditya Garg +Tested-by: Orlando Chamberlain +Signed-off-by: Ard Biesheuvel +Tested-by: Aditya Garg +Link: https://bugzilla.kernel.org/show_bug.cgi?id=215277 +Signed-off-by: Greg Kroah-Hartman +--- + 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] = { diff --git a/queue-5.10/fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch b/queue-5.10/fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch new file mode 100644 index 00000000000..f57a80e2886 --- /dev/null +++ b/queue-5.10/fsnotify-fix-fsnotify-hooks-in-pseudo-filesystems.patch @@ -0,0 +1,124 @@ +From 29044dae2e746949ad4b9cbdbfb248994d1dcdb4 Mon Sep 17 00:00:00 2001 +From: Amir Goldstein +Date: Thu, 20 Jan 2022 23:53:05 +0200 +Subject: fsnotify: fix fsnotify hooks in pseudo filesystems + +From: Amir Goldstein + +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 +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 +Signed-off-by: Jan Kara +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/kvm-x86-update-vcpu-s-runtime-cpuid-on-write-to-msr_ia32_xss.patch b/queue-5.10/kvm-x86-update-vcpu-s-runtime-cpuid-on-write-to-msr_ia32_xss.patch new file mode 100644 index 00000000000..1e5556c7f96 --- /dev/null +++ b/queue-5.10/kvm-x86-update-vcpu-s-runtime-cpuid-on-write-to-msr_ia32_xss.patch @@ -0,0 +1,34 @@ +From 4c282e51e4450b94680d6ca3b10f830483b1f243 Mon Sep 17 00:00:00 2001 +From: Like Xu +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 + +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 +[sean: split out as a separate patch, adjust Fixes tag] +Signed-off-by: Sean Christopherson +Message-Id: <20220126172226.2298529-3-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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) diff --git a/queue-5.10/netfilter-nft_payload-do-not-update-layer-4-checksum-when-mangling-fragments.patch b/queue-5.10/netfilter-nft_payload-do-not-update-layer-4-checksum-when-mangling-fragments.patch new file mode 100644 index 00000000000..812c8dedfa2 --- /dev/null +++ b/queue-5.10/netfilter-nft_payload-do-not-update-layer-4-checksum-when-mangling-fragments.patch @@ -0,0 +1,33 @@ +From 4e1860a3863707e8177329c006d10f9e37e097a8 Mon Sep 17 00:00:00 2001 +From: Pablo Neira Ayuso +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 + +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 +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Florian Westphal +Signed-off-by: Greg Kroah-Hartman +--- + 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); diff --git a/queue-5.10/perf-x86-intel-uncore-fix-cas_count_write-issue-for-icx.patch b/queue-5.10/perf-x86-intel-uncore-fix-cas_count_write-issue-for-icx.patch new file mode 100644 index 00000000000..a04a218a3e4 --- /dev/null +++ b/queue-5.10/perf-x86-intel-uncore-fix-cas_count_write-issue-for-icx.patch @@ -0,0 +1,62 @@ +From 96fd2e89fba1aaada6f4b1e5d25a9d9ecbe1943d Mon Sep 17 00:00:00 2001 +From: Zhengjun Xing +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 + +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 +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Adrian Hunter +Reviewed-by: Kan Liang +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 +--- + 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, diff --git a/queue-5.10/pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch b/queue-5.10/pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch new file mode 100644 index 00000000000..6c48495eb07 --- /dev/null +++ b/queue-5.10/pm-wakeup-simplify-the-output-logic-of-pm_show_wakelocks.patch @@ -0,0 +1,51 @@ +From c9d967b2ce40d71e968eb839f36c936b8a9cf1ea Mon Sep 17 00:00:00 2001 +From: Greg Kroah-Hartman +Date: Thu, 13 Jan 2022 19:44:20 +0100 +Subject: PM: wakeup: simplify the output logic of pm_show_wakelocks() + +From: Greg Kroah-Hartman + +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 +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + 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 diff --git a/queue-5.10/revert-kvm-svm-avoid-infinite-loop-on-npf-from-bad-address.patch b/queue-5.10/revert-kvm-svm-avoid-infinite-loop-on-npf-from-bad-address.patch new file mode 100644 index 00000000000..85f2ec0113b --- /dev/null +++ b/queue-5.10/revert-kvm-svm-avoid-infinite-loop-on-npf-from-bad-address.patch @@ -0,0 +1,60 @@ +From 31c25585695abdf03d6160aa6d829e855b256329 Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 20 Jan 2022 01:07:12 +0000 +Subject: Revert "KVM: SVM: avoid infinite loop on NPF from bad address" + +From: Sean Christopherson + +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 +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Reviewed-by: Liam Merwick +Message-Id: <20220120010719.711476-3-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + 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) + { diff --git a/queue-5.10/series b/queue-5.10/series index d902a82b1cc..6ff098cb99b 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -8,3 +8,16 @@ bpf-guard-against-accessing-null-pt_regs-in-bpf_get_task_stack.patch 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 diff --git a/queue-5.10/tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch b/queue-5.10/tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch new file mode 100644 index 00000000000..7d9094b1f19 --- /dev/null +++ b/queue-5.10/tracing-don-t-inc-err_log-entry-count-if-entry-allocation-fails.patch @@ -0,0 +1,38 @@ +From 67ab5eb71b37b55f7c5522d080a1b42823351776 Mon Sep 17 00:00:00 2001 +From: Tom Zanussi +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 + +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 +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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; + } diff --git a/queue-5.10/tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch b/queue-5.10/tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch new file mode 100644 index 00000000000..62b76df76c9 --- /dev/null +++ b/queue-5.10/tracing-histogram-fix-a-potential-memory-leak-for-kstrdup.patch @@ -0,0 +1,37 @@ +From e629e7b525a179e29d53463d992bdee759c950fb Mon Sep 17 00:00:00 2001 +From: Xiaoke Wang +Date: Tue, 25 Jan 2022 12:07:15 +0800 +Subject: tracing/histogram: Fix a potential memory leak for kstrdup() + +From: Xiaoke Wang + +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 +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + 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; + }