The following commit has been merged into the x86/urgent branch of tip:
Commit-ID: 72cbc8f04fe2fa93443c0fcccb7ad91dfea3d9ce
Gitweb: https://git.kernel.org/tip/72cbc8f04fe2fa93443c0fcccb7ad91dfea3d9ce
Author: Jan Beulich <jbeulich(a)suse.com>
AuthorDate: Thu, 28 Apr 2022 16:50:29 +02:00
Committer: Borislav Petkov <bp(a)suse.de>
CommitterDate: Mon, 15 Aug 2022 10:51:23 +02:00
x86/PAT: Have pat_enabled() properly reflect state when running on Xen
After commit ID in the Fixes: tag, pat_enabled() returns false (because
of PAT initialization being suppressed in the absence of MTRRs being
announced to be available).
This has become a problem: the i915 driver now fails to initialize when
running PV on Xen (i915_gem_object_pin_map() is where I located the
induced failure), and its error handling is flaky enough to (at least
sometimes) result in a hung system.
Yet even beyond that problem the keying of the use of WC mappings to
pat_enabled() (see arch_can_pci_mmap_wc()) means that in particular
graphics frame buffer accesses would have been quite a bit less optimal
than possible.
Arrange for the function to return true in such environments, without
undermining the rest of PAT MSR management logic considering PAT to be
disabled: specifically, no writes to the PAT MSR should occur.
For the new boolean to live in .init.data, init_cache_modes() also needs
moving to .init.text (where it could/should have lived already before).
[ bp: This is the "small fix" variant for stable. It'll get replaced
with a proper PAT and MTRR detection split upstream but that is too
involved for a stable backport.
- additional touchups to commit msg. Use cpu_feature_enabled(). ]
Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT with pat_enabled()")
Signed-off-by: Jan Beulich <jbeulich(a)suse.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Acked-by: Ingo Molnar <mingo(a)kernel.org>
Cc: <stable(a)vger.kernel.org>
Cc: Juergen Gross <jgross(a)suse.com>
Cc: Lucas De Marchi <lucas.demarchi(a)intel.com>
Link: https://lore.kernel.org/r/9385fa60-fa5d-f559-a137-6608408f88b0@suse.com
---
arch/x86/mm/pat/memtype.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/x86/mm/pat/memtype.c b/arch/x86/mm/pat/memtype.c
index d5ef64d..66a209f 100644
--- a/arch/x86/mm/pat/memtype.c
+++ b/arch/x86/mm/pat/memtype.c
@@ -62,6 +62,7 @@
static bool __read_mostly pat_bp_initialized;
static bool __read_mostly pat_disabled = !IS_ENABLED(CONFIG_X86_PAT);
+static bool __initdata pat_force_disabled = !IS_ENABLED(CONFIG_X86_PAT);
static bool __read_mostly pat_bp_enabled;
static bool __read_mostly pat_cm_initialized;
@@ -86,6 +87,7 @@ void pat_disable(const char *msg_reason)
static int __init nopat(char *str)
{
pat_disable("PAT support disabled via boot option.");
+ pat_force_disabled = true;
return 0;
}
early_param("nopat", nopat);
@@ -272,7 +274,7 @@ static void pat_ap_init(u64 pat)
wrmsrl(MSR_IA32_CR_PAT, pat);
}
-void init_cache_modes(void)
+void __init init_cache_modes(void)
{
u64 pat = 0;
@@ -313,6 +315,12 @@ void init_cache_modes(void)
*/
pat = PAT(0, WB) | PAT(1, WT) | PAT(2, UC_MINUS) | PAT(3, UC) |
PAT(4, WB) | PAT(5, WT) | PAT(6, UC_MINUS) | PAT(7, UC);
+ } else if (!pat_force_disabled && cpu_feature_enabled(X86_FEATURE_HYPERVISOR)) {
+ /*
+ * Clearly PAT is enabled underneath. Allow pat_enabled() to
+ * reflect this.
+ */
+ pat_bp_enabled = true;
}
__init_cache_modes(pat);
This bug is marked as fixed by commit:
net: core: netlink: add helper refcount dec and lock function
net: sched: add helper function to take reference to Qdisc
net: sched: extend Qdisc with rcu
net: sched: rename qdisc_destroy() to qdisc_put()
net: sched: use Qdisc rcu API instead of relying on rtnl lock
But I can't find it in any tested tree for more than 90 days.
Is it a correct commit? Please update it by replying:
#syz fix: exact-commit-title
Until then the bug is still considered open and
new crashes with the same signature are ignored.
Hi Sasha,
On 8/13/22 5:50 PM, Sasha Levin wrote:
> This is a note to let you know that I've just added the patch titled
>
> genirq: GENERIC_IRQ_IPI depends on SMP
>
> to the 5.4-stable tree which can be found at:
> http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
>
> The filename of the patch is:
> genirq-generic_irq_ipi-depends-on-smp.patch
> and it can be found in the queue-5.4 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let <stable(a)vger.kernel.org> know about it.
This commit should not be backported further than 8190cc572981
("irqchip/mips-gic: Only register IPI domain when SMP is enabled"), which it
depends on. It looks like that commit only went back to 5.10.
Regards,
Samuel
> commit 1ac66168f6a589c3f91104eb692fab83bae9ed73
> Author: Samuel Holland <samuel(a)sholland.org>
> Date: Fri Jul 1 15:00:50 2022 -0500
>
> genirq: GENERIC_IRQ_IPI depends on SMP
>
> [ Upstream commit 0f5209fee90b4544c58b4278d944425292789967 ]
>
> The generic IPI code depends on the IRQ affinity mask being allocated
> and initialized. This will not be the case if SMP is disabled. Fix up
> the remaining driver that selected GENERIC_IRQ_IPI in a non-SMP config.
>
> Reported-by: kernel test robot <lkp(a)intel.com>
> Signed-off-by: Samuel Holland <samuel(a)sholland.org>
> Signed-off-by: Marc Zyngier <maz(a)kernel.org>
> Link: https://lore.kernel.org/r/20220701200056.46555-3-samuel@sholland.org
> Signed-off-by: Sasha Levin <sashal(a)kernel.org>
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 20f44ef9c4c9..e50b5516bbef 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -178,7 +178,7 @@ config MADERA_IRQ
> config IRQ_MIPS_CPU
> bool
> select GENERIC_IRQ_CHIP
> - select GENERIC_IRQ_IPI if SYS_SUPPORTS_MULTITHREADING
> + select GENERIC_IRQ_IPI if SMP && SYS_SUPPORTS_MULTITHREADING
> select IRQ_DOMAIN
> select IRQ_DOMAIN_HIERARCHY if GENERIC_IRQ_IPI
> select GENERIC_IRQ_EFFECTIVE_AFF_MASK
> diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
> index 4e11120265c7..3a8a631044f0 100644
> --- a/kernel/irq/Kconfig
> +++ b/kernel/irq/Kconfig
> @@ -81,6 +81,7 @@ config IRQ_FASTEOI_HIERARCHY_HANDLERS
> # Generic IRQ IPI support
> config GENERIC_IRQ_IPI
> bool
> + depends on SMP
> select IRQ_DOMAIN_HIERARCHY
>
> # Generic MSI interrupt support
>
From: Nadav Amit <namit(a)vmware.com>
When kprobes emulates JNG/JNLE instructions on x86 it uses the wrong
condition. For JNG (opcode: 0F 8E), according to Intel SDM, the jump is
performed if (ZF == 1 or SF != OF). However the kernel emulation
currently uses 'and' instead of 'or'.
As a result, setting a kprobe on JNG/JNLE might cause the kernel to
behave incorrectly whenever the kprobe is hit.
Fix by changing the 'and' to 'or'.
Cc: Masami Hiramatsu <mhiramat(a)kernel.org>
Cc: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Cc: Andy Lutomirski <luto(a)kernel.org>
Cc: stable(a)vger.kernel.org
Fixes: 6256e668b7af ("x86/kprobes: Use int3 instead of debug trap for single-step")
Signed-off-by: Nadav Amit <namit(a)vmware.com>
---
arch/x86/kernel/kprobes/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
index 74167dc5f55e..4c3c27b6aea3 100644
--- a/arch/x86/kernel/kprobes/core.c
+++ b/arch/x86/kernel/kprobes/core.c
@@ -505,7 +505,7 @@ static void kprobe_emulate_jcc(struct kprobe *p, struct pt_regs *regs)
match = ((regs->flags & X86_EFLAGS_SF) >> X86_EFLAGS_SF_BIT) ^
((regs->flags & X86_EFLAGS_OF) >> X86_EFLAGS_OF_BIT);
if (p->ainsn.jcc.type >= 0xe)
- match = match && (regs->flags & X86_EFLAGS_ZF);
+ match = match || (regs->flags & X86_EFLAGS_ZF);
}
__kprobe_emulate_jmp(p, regs, (match && !invert) || (!match && invert));
}
--
2.25.1