From: Greg Kroah-Hartman Date: Mon, 11 Apr 2022 07:56:17 +0000 (+0200) Subject: 4.19-stable patches X-Git-Tag: v4.9.310~80 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=021141aadd6376d091ea6be48b5f7ab2334d93ec;p=thirdparty%2Fkernel%2Fstable-queue.git 4.19-stable patches added patches: btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch x86-pm-save-the-msr-validity-status-at-context-setup.patch x86-speculation-restore-speculation-related-msrs-during-s3-resume.patch --- diff --git a/queue-4.19/btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch b/queue-4.19/btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch new file mode 100644 index 00000000000..9de836bed3e --- /dev/null +++ b/queue-4.19/btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch @@ -0,0 +1,93 @@ +From b642b52d0b50f4d398cb4293f64992d0eed2e2ce Mon Sep 17 00:00:00 2001 +From: Ethan Lien +Date: Mon, 7 Mar 2022 18:00:04 +0800 +Subject: btrfs: fix qgroup reserve overflow the qgroup limit +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ethan Lien + +commit b642b52d0b50f4d398cb4293f64992d0eed2e2ce upstream. + +We use extent_changeset->bytes_changed in qgroup_reserve_data() to record +how many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the +bytes_changed is set as "unsigned int", and it will overflow if we try to +fallocate a range larger than 4GiB. The result is we reserve less bytes +and eventually break the qgroup limit. + +Unlike regular buffered/direct write, which we use one changeset for +each ordered extent, which can never be larger than 256M. For +fallocate, we use one changeset for the whole range, thus it no longer +respects the 256M per extent limit, and caused the problem. + +The following example test script reproduces the problem: + + $ cat qgroup-overflow.sh + #!/bin/bash + + DEV=/dev/sdj + MNT=/mnt/sdj + + mkfs.btrfs -f $DEV + mount $DEV $MNT + + # Set qgroup limit to 2GiB. + btrfs quota enable $MNT + btrfs qgroup limit 2G $MNT + + # Try to fallocate a 3GiB file. This should fail. + echo + echo "Try to fallocate a 3GiB file..." + fallocate -l 3G $MNT/3G.file + + # Try to fallocate a 5GiB file. + echo + echo "Try to fallocate a 5GiB file..." + fallocate -l 5G $MNT/5G.file + + # See we break the qgroup limit. + echo + sync + btrfs qgroup show -r $MNT + + umount $MNT + +When running the test: + + $ ./qgroup-overflow.sh + (...) + + Try to fallocate a 3GiB file... + fallocate: fallocate failed: Disk quota exceeded + + Try to fallocate a 5GiB file... + + qgroupid         rfer         excl     max_rfer + --------         ----         ----     -------- + 0/5           5.00GiB      5.00GiB      2.00GiB + +Since we have no control of how bytes_changed is used, it's better to +set it to u64. + +CC: stable@vger.kernel.org # 4.14+ +Reviewed-by: Qu Wenruo +Signed-off-by: Ethan Lien +Reviewed-by: David Sterba +Signed-off-by: David Sterba +Signed-off-by: Greg Kroah-Hartman +--- + fs/btrfs/extent_io.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/btrfs/extent_io.h ++++ b/fs/btrfs/extent_io.h +@@ -197,7 +197,7 @@ struct extent_buffer { + */ + struct extent_changeset { + /* How many bytes are set/cleared in this operation */ +- unsigned int bytes_changed; ++ u64 bytes_changed; + + /* Changed ranges */ + struct ulist range_changed; diff --git a/queue-4.19/series b/queue-4.19/series index e7edce8c767..94bae8d1206 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -315,3 +315,6 @@ revert-mmc-sdhci-xenon-fix-annoying-1.8v-regulator-warning.patch mmc-renesas_sdhi-don-t-overwrite-tap-settings-when-hs400-tuning-is-complete.patch mmmremap.c-avoid-pointless-invalidate_range_start-end-on-mremap-old_size-0.patch mm-mempolicy-fix-mpol_new-leak-in-shared_policy_replace.patch +x86-pm-save-the-msr-validity-status-at-context-setup.patch +x86-speculation-restore-speculation-related-msrs-during-s3-resume.patch +btrfs-fix-qgroup-reserve-overflow-the-qgroup-limit.patch diff --git a/queue-4.19/x86-pm-save-the-msr-validity-status-at-context-setup.patch b/queue-4.19/x86-pm-save-the-msr-validity-status-at-context-setup.patch new file mode 100644 index 00000000000..62eef4201fc --- /dev/null +++ b/queue-4.19/x86-pm-save-the-msr-validity-status-at-context-setup.patch @@ -0,0 +1,55 @@ +From 73924ec4d560257004d5b5116b22a3647661e364 Mon Sep 17 00:00:00 2001 +From: Pawan Gupta +Date: Mon, 4 Apr 2022 17:34:19 -0700 +Subject: x86/pm: Save the MSR validity status at context setup + +From: Pawan Gupta + +commit 73924ec4d560257004d5b5116b22a3647661e364 upstream. + +The mechanism to save/restore MSRs during S3 suspend/resume checks for +the MSR validity during suspend, and only restores the MSR if its a +valid MSR. This is not optimal, as an invalid MSR will unnecessarily +throw an exception for every suspend cycle. The more invalid MSRs, +higher the impact will be. + +Check and save the MSR validity at setup. This ensures that only valid +MSRs that are guaranteed to not throw an exception will be attempted +during suspend. + +Fixes: 7a9c2dd08ead ("x86/pm: Introduce quirk framework to save/restore extra MSR registers around suspend/resume") +Suggested-by: Dave Hansen +Signed-off-by: Pawan Gupta +Reviewed-by: Dave Hansen +Acked-by: Borislav Petkov +Cc: stable@vger.kernel.org +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/power/cpu.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +--- a/arch/x86/power/cpu.c ++++ b/arch/x86/power/cpu.c +@@ -41,7 +41,8 @@ static void msr_save_context(struct save + struct saved_msr *end = msr + ctxt->saved_msrs.num; + + while (msr < end) { +- msr->valid = !rdmsrl_safe(msr->info.msr_no, &msr->info.reg.q); ++ if (msr->valid) ++ rdmsrl(msr->info.msr_no, msr->info.reg.q); + msr++; + } + } +@@ -426,8 +427,10 @@ static int msr_build_context(const u32 * + } + + for (i = saved_msrs->num, j = 0; i < total_num; i++, j++) { ++ u64 dummy; ++ + msr_array[i].info.msr_no = msr_id[j]; +- msr_array[i].valid = false; ++ msr_array[i].valid = !rdmsrl_safe(msr_id[j], &dummy); + msr_array[i].info.reg.q = 0; + } + saved_msrs->num = total_num; diff --git a/queue-4.19/x86-speculation-restore-speculation-related-msrs-during-s3-resume.patch b/queue-4.19/x86-speculation-restore-speculation-related-msrs-during-s3-resume.patch new file mode 100644 index 00000000000..e8d3aecf2de --- /dev/null +++ b/queue-4.19/x86-speculation-restore-speculation-related-msrs-during-s3-resume.patch @@ -0,0 +1,60 @@ +From e2a1256b17b16f9b9adf1b6fea56819e7b68e463 Mon Sep 17 00:00:00 2001 +From: Pawan Gupta +Date: Mon, 4 Apr 2022 17:35:45 -0700 +Subject: x86/speculation: Restore speculation related MSRs during S3 resume + +From: Pawan Gupta + +commit e2a1256b17b16f9b9adf1b6fea56819e7b68e463 upstream. + +After resuming from suspend-to-RAM, the MSRs that control CPU's +speculative execution behavior are not being restored on the boot CPU. + +These MSRs are used to mitigate speculative execution vulnerabilities. +Not restoring them correctly may leave the CPU vulnerable. Secondary +CPU's MSRs are correctly being restored at S3 resume by +identify_secondary_cpu(). + +During S3 resume, restore these MSRs for boot CPU when restoring its +processor state. + +Fixes: 772439717dbf ("x86/bugs/intel: Set proper CPU features and setup RDS") +Reported-by: Neelima Krishnan +Signed-off-by: Pawan Gupta +Tested-by: Neelima Krishnan +Acked-by: Borislav Petkov +Reviewed-by: Dave Hansen +Cc: stable@vger.kernel.org +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/power/cpu.c | 14 ++++++++++++++ + 1 file changed, 14 insertions(+) + +--- a/arch/x86/power/cpu.c ++++ b/arch/x86/power/cpu.c +@@ -517,10 +517,24 @@ static int pm_cpu_check(const struct x86 + return ret; + } + ++static void pm_save_spec_msr(void) ++{ ++ u32 spec_msr_id[] = { ++ MSR_IA32_SPEC_CTRL, ++ MSR_IA32_TSX_CTRL, ++ MSR_TSX_FORCE_ABORT, ++ MSR_IA32_MCU_OPT_CTRL, ++ MSR_AMD64_LS_CFG, ++ }; ++ ++ msr_build_context(spec_msr_id, ARRAY_SIZE(spec_msr_id)); ++} ++ + static int pm_check_save_msr(void) + { + dmi_check_system(msr_save_dmi_table); + pm_cpu_check(msr_save_cpu_table); ++ pm_save_spec_msr(); + + return 0; + }