From 3f1a538f5b138d0cddb05925206ea79272d51777 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 3 Dec 2022 12:01:31 +0100 Subject: [PATCH] 4.19-stable patches added patches: error-injection-add-prompt-for-function-error-injection.patch nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch pinctrl-intel-save-and-restore-pins-in-direct-irq-mode.patch tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch x86-bugs-make-sure-msr_spec_ctrl-is-updated-properly-upon-resume-from-s3.patch --- ...-prompt-for-function-error-injection.patch | 49 ++++++ ...ce-in-nilfs_palloc_commit_free_entry.patch | 107 +++++++++++++ ...-and-restore-pins-in-direct-irq-mode.patch | 85 +++++++++++ queue-4.19/series | 5 + ...-gnuplot-use-grep-e-instead-of-egrep.patch | 57 +++++++ ...updated-properly-upon-resume-from-s3.patch | 140 ++++++++++++++++++ 6 files changed, 443 insertions(+) create mode 100644 queue-4.19/error-injection-add-prompt-for-function-error-injection.patch create mode 100644 queue-4.19/nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch create mode 100644 queue-4.19/pinctrl-intel-save-and-restore-pins-in-direct-irq-mode.patch create mode 100644 queue-4.19/tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch create mode 100644 queue-4.19/x86-bugs-make-sure-msr_spec_ctrl-is-updated-properly-upon-resume-from-s3.patch diff --git a/queue-4.19/error-injection-add-prompt-for-function-error-injection.patch b/queue-4.19/error-injection-add-prompt-for-function-error-injection.patch new file mode 100644 index 00000000000..fc813e6c54a --- /dev/null +++ b/queue-4.19/error-injection-add-prompt-for-function-error-injection.patch @@ -0,0 +1,49 @@ +From a4412fdd49dc011bcc2c0d81ac4cab7457092650 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Mon, 21 Nov 2022 10:44:03 -0500 +Subject: error-injection: Add prompt for function error injection + +From: Steven Rostedt (Google) + +commit a4412fdd49dc011bcc2c0d81ac4cab7457092650 upstream. + +The config to be able to inject error codes into any function annotated +with ALLOW_ERROR_INJECTION() is enabled when FUNCTION_ERROR_INJECTION is +enabled. But unfortunately, this is always enabled on x86 when KPROBES +is enabled, and there's no way to turn it off. + +As kprobes is useful for observability of the kernel, it is useful to +have it enabled in production environments. But error injection should +be avoided. Add a prompt to the config to allow it to be disabled even +when kprobes is enabled, and get rid of the "def_bool y". + +This is a kernel debug feature (it's in Kconfig.debug), and should have +never been something enabled by default. + +Cc: stable@vger.kernel.org +Fixes: 540adea3809f6 ("error-injection: Separate error-injection from kprobe") +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + lib/Kconfig.debug | 8 +++++++- + 1 file changed, 7 insertions(+), 1 deletion(-) + +--- a/lib/Kconfig.debug ++++ b/lib/Kconfig.debug +@@ -1510,8 +1510,14 @@ config NETDEV_NOTIFIER_ERROR_INJECT + If unsure, say N. + + config FUNCTION_ERROR_INJECTION +- def_bool y ++ bool "Fault-injections of functions" + depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES ++ help ++ Add fault injections into various functions that are annotated with ++ ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return ++ value of theses functions. This is useful to test error paths of code. ++ ++ If unsure, say N + + config FAULT_INJECTION + bool "Fault-injection framework" diff --git a/queue-4.19/nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch b/queue-4.19/nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch new file mode 100644 index 00000000000..2c38b47d535 --- /dev/null +++ b/queue-4.19/nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch @@ -0,0 +1,107 @@ +From f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4 Mon Sep 17 00:00:00 2001 +From: ZhangPeng +Date: Sat, 19 Nov 2022 21:05:42 +0900 +Subject: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry() + +From: ZhangPeng + +commit f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4 upstream. + +Syzbot reported a null-ptr-deref bug: + + NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP + frequency < 30 seconds + general protection fault, probably for non-canonical address + 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN + KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] + CPU: 1 PID: 3603 Comm: segctord Not tainted + 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0 + Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google + 10/11/2022 + RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0 + fs/nilfs2/alloc.c:608 + Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00 + 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02 + 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7 + RSP: 0018:ffffc90003dff830 EFLAGS: 00010212 + RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d + RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010 + RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f + R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158 + R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004 + FS: 0000000000000000(0000) GS:ffff8880b9b00000(0000) + knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0 + Call Trace: + + nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline] + nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193 + nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236 + nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940 + nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline] + nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline] + nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088 + nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337 + nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568 + nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018 + nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067 + nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline] + nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline] + nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045 + nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379 + nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline] + nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570 + kthread+0x2e4/0x3a0 kernel/kthread.c:376 + ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306 + + ... + +If DAT metadata file is corrupted on disk, there is a case where +req->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during +a b-tree operation that cascadingly updates ancestor nodes of the b-tree, +because nilfs_dat_commit_alloc() for a lower level block can initialize +the blocknr on the same DAT entry between nilfs_dat_prepare_end() and +nilfs_dat_commit_end(). + +If this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free() +without valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and +causes the NULL pointer dereference above in +nilfs_palloc_commit_free_entry() function, which leads to a crash. + +Fix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh +before nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free(). + +This also calls nilfs_error() in that case to notify that there is a fatal +flaw in the filesystem metadata and prevent further operations. + +Link: https://lkml.kernel.org/r/00000000000097c20205ebaea3d6@google.com +Link: https://lkml.kernel.org/r/20221114040441.1649940-1-zhangpeng362@huawei.com +Link: https://lkml.kernel.org/r/20221119120542.17204-1-konishi.ryusuke@gmail.com +Signed-off-by: ZhangPeng +Signed-off-by: Ryusuke Konishi +Reported-by: syzbot+ebe05ee8e98f755f61d0@syzkaller.appspotmail.com +Tested-by: Ryusuke Konishi +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/nilfs2/dat.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/fs/nilfs2/dat.c ++++ b/fs/nilfs2/dat.c +@@ -111,6 +111,13 @@ static void nilfs_dat_commit_free(struct + kunmap_atomic(kaddr); + + nilfs_dat_commit_entry(dat, req); ++ ++ if (unlikely(req->pr_desc_bh == NULL || req->pr_bitmap_bh == NULL)) { ++ nilfs_error(dat->i_sb, ++ "state inconsistency probably due to duplicate use of vblocknr = %llu", ++ (unsigned long long)req->pr_entry_nr); ++ return; ++ } + nilfs_palloc_commit_free_entry(dat, req); + } + diff --git a/queue-4.19/pinctrl-intel-save-and-restore-pins-in-direct-irq-mode.patch b/queue-4.19/pinctrl-intel-save-and-restore-pins-in-direct-irq-mode.patch new file mode 100644 index 00000000000..81027fe4df3 --- /dev/null +++ b/queue-4.19/pinctrl-intel-save-and-restore-pins-in-direct-irq-mode.patch @@ -0,0 +1,85 @@ +From 6989ea4881c8944fbf04378418bb1af63d875ef8 Mon Sep 17 00:00:00 2001 +From: Andy Shevchenko +Date: Fri, 25 Nov 2022 00:29:26 +0200 +Subject: pinctrl: intel: Save and restore pins in "direct IRQ" mode + +From: Andy Shevchenko + +commit 6989ea4881c8944fbf04378418bb1af63d875ef8 upstream. + +The firmware on some systems may configure GPIO pins to be +an interrupt source in so called "direct IRQ" mode. In such +cases the GPIO controller driver has no idea if those pins +are being used or not. At the same time, there is a known bug +in the firmwares that don't restore the pin settings correctly +after suspend, i.e. by an unknown reason the Rx value becomes +inverted. + +Hence, let's save and restore the pins that are configured +as GPIOs in the input mode with GPIROUTIOXAPIC bit set. + +Cc: stable@vger.kernel.org +Reported-and-tested-by: Dale Smith +Reported-and-tested-by: John Harris +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214749 +Signed-off-by: Andy Shevchenko +Acked-by: Mika Westerberg +Link: https://lore.kernel.org/r/20221124222926.72326-1-andriy.shevchenko@linux.intel.com +Signed-off-by: Linus Walleij +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pinctrl/intel/pinctrl-intel.c | 27 ++++++++++++++++++++++++++- + 1 file changed, 26 insertions(+), 1 deletion(-) + +--- a/drivers/pinctrl/intel/pinctrl-intel.c ++++ b/drivers/pinctrl/intel/pinctrl-intel.c +@@ -423,9 +423,14 @@ static void __intel_gpio_set_direction(v + writel(value, padcfg0); + } + ++static int __intel_gpio_get_gpio_mode(u32 value) ++{ ++ return (value & PADCFG0_PMODE_MASK) >> PADCFG0_PMODE_SHIFT; ++} ++ + static int intel_gpio_get_gpio_mode(void __iomem *padcfg0) + { +- return (readl(padcfg0) & PADCFG0_PMODE_MASK) >> PADCFG0_PMODE_SHIFT; ++ return __intel_gpio_get_gpio_mode(readl(padcfg0)); + } + + static void intel_gpio_set_gpio_mode(void __iomem *padcfg0) +@@ -1429,6 +1434,7 @@ EXPORT_SYMBOL_GPL(intel_pinctrl_probe); + static bool intel_pinctrl_should_save(struct intel_pinctrl *pctrl, unsigned pin) + { + const struct pin_desc *pd = pin_desc_get(pctrl->pctldev, pin); ++ u32 value; + + if (!pd || !intel_pad_usable(pctrl, pin)) + return false; +@@ -1443,6 +1449,25 @@ static bool intel_pinctrl_should_save(st + gpiochip_line_is_irq(&pctrl->chip, pin)) + return true; + ++ /* ++ * The firmware on some systems may configure GPIO pins to be ++ * an interrupt source in so called "direct IRQ" mode. In such ++ * cases the GPIO controller driver has no idea if those pins ++ * are being used or not. At the same time, there is a known bug ++ * in the firmwares that don't restore the pin settings correctly ++ * after suspend, i.e. by an unknown reason the Rx value becomes ++ * inverted. ++ * ++ * Hence, let's save and restore the pins that are configured ++ * as GPIOs in the input mode with GPIROUTIOXAPIC bit set. ++ * ++ * See https://bugzilla.kernel.org/show_bug.cgi?id=214749. ++ */ ++ value = readl(intel_get_padcfg(pctrl, pin, PADCFG0)); ++ if ((value & PADCFG0_GPIROUTIOXAPIC) && (value & PADCFG0_GPIOTXDIS) && ++ (__intel_gpio_get_gpio_mode(value) == PADCFG0_PMODE_GPIO)) ++ return true; ++ + return false; + } + diff --git a/queue-4.19/series b/queue-4.19/series index 66a87979e7f..3938210aa3c 100644 --- a/queue-4.19/series +++ b/queue-4.19/series @@ -88,3 +88,8 @@ net-ethernet-renesas-ravb-fix-promiscuous-mode-after.patch hwmon-coretemp-check-for-null-before-removing-sysfs-.patch hwmon-coretemp-fix-pci-device-refcount-leak-in-nv1a_.patch btrfs-qgroup-fix-sleep-from-invalid-context-bug-in-b.patch +error-injection-add-prompt-for-function-error-injection.patch +tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch +nilfs2-fix-null-pointer-dereference-in-nilfs_palloc_commit_free_entry.patch +x86-bugs-make-sure-msr_spec_ctrl-is-updated-properly-upon-resume-from-s3.patch +pinctrl-intel-save-and-restore-pins-in-direct-irq-mode.patch diff --git a/queue-4.19/tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch b/queue-4.19/tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch new file mode 100644 index 00000000000..55680b6b338 --- /dev/null +++ b/queue-4.19/tools-vm-slabinfo-gnuplot-use-grep-e-instead-of-egrep.patch @@ -0,0 +1,57 @@ +From a435874bf626f55d7147026b059008c8de89fbb8 Mon Sep 17 00:00:00 2001 +From: Tiezhu Yang +Date: Sat, 19 Nov 2022 10:36:59 +0800 +Subject: tools/vm/slabinfo-gnuplot: use "grep -E" instead of "egrep" + +From: Tiezhu Yang + +commit a435874bf626f55d7147026b059008c8de89fbb8 upstream. + +The latest version of grep claims the egrep is now obsolete so the build +now contains warnings that look like: + + egrep: warning: egrep is obsolescent; using grep -E + +fix this up by moving the related file to use "grep -E" instead. + + sed -i "s/egrep/grep -E/g" `grep egrep -rwl tools/vm` + +Here are the steps to install the latest grep: + + wget http://ftp.gnu.org/gnu/grep/grep-3.8.tar.gz + tar xf grep-3.8.tar.gz + cd grep-3.8 && ./configure && make + sudo make install + export PATH=/usr/local/bin:$PATH + +Link: https://lkml.kernel.org/r/1668825419-30584-1-git-send-email-yangtiezhu@loongson.cn +Signed-off-by: Tiezhu Yang +Reviewed-by: Sergey Senozhatsky +Cc: Vlastimil Babka +Cc: +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + tools/vm/slabinfo-gnuplot.sh | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/tools/vm/slabinfo-gnuplot.sh ++++ b/tools/vm/slabinfo-gnuplot.sh +@@ -157,7 +157,7 @@ do_preprocess() + let lines=3 + out=`basename "$in"`"-slabs-by-loss" + `cat "$in" | grep -A "$lines" 'Slabs sorted by loss' |\ +- egrep -iv '\-\-|Name|Slabs'\ ++ grep -E -iv '\-\-|Name|Slabs'\ + | awk '{print $1" "$4+$2*$3" "$4}' > "$out"` + if [ $? -eq 0 ]; then + do_slabs_plotting "$out" +@@ -166,7 +166,7 @@ do_preprocess() + let lines=3 + out=`basename "$in"`"-slabs-by-size" + `cat "$in" | grep -A "$lines" 'Slabs sorted by size' |\ +- egrep -iv '\-\-|Name|Slabs'\ ++ grep -E -iv '\-\-|Name|Slabs'\ + | awk '{print $1" "$4" "$4-$2*$3}' > "$out"` + if [ $? -eq 0 ]; then + do_slabs_plotting "$out" diff --git a/queue-4.19/x86-bugs-make-sure-msr_spec_ctrl-is-updated-properly-upon-resume-from-s3.patch b/queue-4.19/x86-bugs-make-sure-msr_spec_ctrl-is-updated-properly-upon-resume-from-s3.patch new file mode 100644 index 00000000000..3e81a0a772f --- /dev/null +++ b/queue-4.19/x86-bugs-make-sure-msr_spec_ctrl-is-updated-properly-upon-resume-from-s3.patch @@ -0,0 +1,140 @@ +From 66065157420c5b9b3f078f43d313c153e1ff7f83 Mon Sep 17 00:00:00 2001 +From: Pawan Gupta +Date: Wed, 30 Nov 2022 07:25:51 -0800 +Subject: x86/bugs: Make sure MSR_SPEC_CTRL is updated properly upon resume from S3 + +From: Pawan Gupta + +commit 66065157420c5b9b3f078f43d313c153e1ff7f83 upstream. + +The "force" argument to write_spec_ctrl_current() is currently ambiguous +as it does not guarantee the MSR write. This is due to the optimization +that writes to the MSR happen only when the new value differs from the +cached value. + +This is fine in most cases, but breaks for S3 resume when the cached MSR +value gets out of sync with the hardware MSR value due to S3 resetting +it. + +When x86_spec_ctrl_current is same as x86_spec_ctrl_base, the MSR write +is skipped. Which results in SPEC_CTRL mitigations not getting restored. + +Move the MSR write from write_spec_ctrl_current() to a new function that +unconditionally writes to the MSR. Update the callers accordingly and +rename functions. + + [ bp: Rework a bit. ] + +Fixes: caa0ff24d5d0 ("x86/bugs: Keep a per-CPU IA32_SPEC_CTRL value") +Suggested-by: Borislav Petkov +Signed-off-by: Pawan Gupta +Signed-off-by: Borislav Petkov (AMD) +Reviewed-by: Thomas Gleixner +Cc: +Link: https://lore.kernel.org/r/806d39b0bfec2fe8f50dc5446dff20f5bb24a959.1669821572.git.pawan.kumar.gupta@linux.intel.com +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/include/asm/nospec-branch.h | 2 +- + arch/x86/kernel/cpu/bugs.c | 21 ++++++++++++++------- + arch/x86/kernel/process.c | 2 +- + 3 files changed, 16 insertions(+), 9 deletions(-) + +--- a/arch/x86/include/asm/nospec-branch.h ++++ b/arch/x86/include/asm/nospec-branch.h +@@ -317,7 +317,7 @@ static inline void indirect_branch_predi + /* The Intel SPEC CTRL MSR base value cache */ + extern u64 x86_spec_ctrl_base; + DECLARE_PER_CPU(u64, x86_spec_ctrl_current); +-extern void write_spec_ctrl_current(u64 val, bool force); ++extern void update_spec_ctrl_cond(u64 val); + extern u64 spec_ctrl_current(void); + + /* +--- a/arch/x86/kernel/cpu/bugs.c ++++ b/arch/x86/kernel/cpu/bugs.c +@@ -58,11 +58,18 @@ EXPORT_SYMBOL_GPL(x86_spec_ctrl_current) + + static DEFINE_MUTEX(spec_ctrl_mutex); + ++/* Update SPEC_CTRL MSR and its cached copy unconditionally */ ++static void update_spec_ctrl(u64 val) ++{ ++ this_cpu_write(x86_spec_ctrl_current, val); ++ wrmsrl(MSR_IA32_SPEC_CTRL, val); ++} ++ + /* + * Keep track of the SPEC_CTRL MSR value for the current task, which may differ + * from x86_spec_ctrl_base due to STIBP/SSB in __speculation_ctrl_update(). + */ +-void write_spec_ctrl_current(u64 val, bool force) ++void update_spec_ctrl_cond(u64 val) + { + if (this_cpu_read(x86_spec_ctrl_current) == val) + return; +@@ -73,7 +80,7 @@ void write_spec_ctrl_current(u64 val, bo + * When KERNEL_IBRS this MSR is written on return-to-user, unless + * forced the update can be delayed until that time. + */ +- if (force || !cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS)) ++ if (!cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS)) + wrmsrl(MSR_IA32_SPEC_CTRL, val); + } + +@@ -1194,7 +1201,7 @@ static void __init spec_ctrl_disable_ker + + if (ia32_cap & ARCH_CAP_RRSBA) { + x86_spec_ctrl_base |= SPEC_CTRL_RRSBA_DIS_S; +- write_spec_ctrl_current(x86_spec_ctrl_base, true); ++ update_spec_ctrl(x86_spec_ctrl_base); + } + } + +@@ -1316,7 +1323,7 @@ static void __init spectre_v2_select_mit + + if (spectre_v2_in_ibrs_mode(mode)) { + x86_spec_ctrl_base |= SPEC_CTRL_IBRS; +- write_spec_ctrl_current(x86_spec_ctrl_base, true); ++ update_spec_ctrl(x86_spec_ctrl_base); + } + + switch (mode) { +@@ -1420,7 +1427,7 @@ static void __init spectre_v2_select_mit + static void update_stibp_msr(void * __unused) + { + u64 val = spec_ctrl_current() | (x86_spec_ctrl_base & SPEC_CTRL_STIBP); +- write_spec_ctrl_current(val, true); ++ update_spec_ctrl(val); + } + + /* Update x86_spec_ctrl_base in case SMT state changed. */ +@@ -1653,7 +1660,7 @@ static enum ssb_mitigation __init __ssb_ + x86_amd_ssb_disable(); + } else { + x86_spec_ctrl_base |= SPEC_CTRL_SSBD; +- write_spec_ctrl_current(x86_spec_ctrl_base, true); ++ update_spec_ctrl(x86_spec_ctrl_base); + } + } + +@@ -1858,7 +1865,7 @@ int arch_prctl_spec_ctrl_get(struct task + void x86_spec_ctrl_setup_ap(void) + { + if (boot_cpu_has(X86_FEATURE_MSR_SPEC_CTRL)) +- write_spec_ctrl_current(x86_spec_ctrl_base, true); ++ update_spec_ctrl(x86_spec_ctrl_base); + + if (ssb_mode == SPEC_STORE_BYPASS_DISABLE) + x86_amd_ssb_disable(); +--- a/arch/x86/kernel/process.c ++++ b/arch/x86/kernel/process.c +@@ -434,7 +434,7 @@ static __always_inline void __speculatio + } + + if (updmsr) +- write_spec_ctrl_current(msr, false); ++ update_spec_ctrl_cond(msr); + } + + static unsigned long speculation_ctrl_update_tif(struct task_struct *tsk) -- 2.47.3