--- /dev/null
+From a4412fdd49dc011bcc2c0d81ac4cab7457092650 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+Date: Mon, 21 Nov 2022 10:44:03 -0500
+Subject: error-injection: Add prompt for function error injection
+
+From: Steven Rostedt (Google) <rostedt@goodmis.org>
+
+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) <rostedt@goodmis.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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"
--- /dev/null
+From f0a0ccda18d6fd826d7c7e7ad48a6ed61c20f8b4 Mon Sep 17 00:00:00 2001
+From: ZhangPeng <zhangpeng362@huawei.com>
+Date: Sat, 19 Nov 2022 21:05:42 +0900
+Subject: nilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()
+
+From: ZhangPeng <zhangpeng362@huawei.com>
+
+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:
+ <TASK>
+ 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
+ </TASK>
+ ...
+
+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 <zhangpeng362@huawei.com>
+Signed-off-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Reported-by: syzbot+ebe05ee8e98f755f61d0@syzkaller.appspotmail.com
+Tested-by: Ryusuke Konishi <konishi.ryusuke@gmail.com>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
--- /dev/null
+From 6989ea4881c8944fbf04378418bb1af63d875ef8 Mon Sep 17 00:00:00 2001
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Date: Fri, 25 Nov 2022 00:29:26 +0200
+Subject: pinctrl: intel: Save and restore pins in "direct IRQ" mode
+
+From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+
+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 <dalepsmith@gmail.com>
+Reported-and-tested-by: John Harris <jmharris@gmail.com>
+BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=214749
+Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
+Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
+Link: https://lore.kernel.org/r/20221124222926.72326-1-andriy.shevchenko@linux.intel.com
+Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
+
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
--- /dev/null
+From a435874bf626f55d7147026b059008c8de89fbb8 Mon Sep 17 00:00:00 2001
+From: Tiezhu Yang <yangtiezhu@loongson.cn>
+Date: Sat, 19 Nov 2022 10:36:59 +0800
+Subject: tools/vm/slabinfo-gnuplot: use "grep -E" instead of "egrep"
+
+From: Tiezhu Yang <yangtiezhu@loongson.cn>
+
+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 <yangtiezhu@loongson.cn>
+Reviewed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
+Cc: Vlastimil Babka <vbabka@suse.cz>
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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"
--- /dev/null
+From 66065157420c5b9b3f078f43d313c153e1ff7f83 Mon Sep 17 00:00:00 2001
+From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
+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 <pawan.kumar.gupta@linux.intel.com>
+
+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 <bp@alien8.de>
+Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/806d39b0bfec2fe8f50dc5446dff20f5bb24a959.1669821572.git.pawan.kumar.gupta@linux.intel.com
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
projects / thirdparty / kernel / stable-queue.git / commitdiff
