On Tue, Oct 13, 2020 at 11:56:53AM -0700, Dave Hansen wrote:
@@ -548,6 +549,11 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code, unsigned long ad (error_code & X86_PF_PK) ? "protection keys violation" : "permissions violation"); +#ifdef CONFIG_ARCH_HAS_SUPERVISOR_PKEYS
- if (irq_state && (error_code & X86_PF_PK))
pr_alert("PKRS: 0x%x\n", irq_state->pkrs);+#endif
This means everyone will see 'PKRS: 0x0', even if they're on non-PKS hardware. I think I'd rather have this only show PKRS when we're on cpu_feature_enabled(PKS) hardware.
Good catch, thanks.
...
@@ -1148,14 +1156,15 @@ static int fault_in_kernel_space(unsigned long address) */ static void do_kern_addr_fault(struct pt_regs *regs, unsigned long hw_error_code,
unsigned long address)
unsigned long address, irqentry_state_t *irq_state){ /*
* Protection keys exceptions only happen on user pages. We* have no user pages in the kernel portion of the address* space, so do not expect them here.
* If protection keys are not enabled for kernel space* do not expect Pkey errors here.Let's fix the double-negative:
/* * PF_PK is only expected on kernel addresses whenn * supervisor pkeys are enabled: */
done. thanks.
- WARN_ON_ONCE(hw_error_code & X86_PF_PK);
- if (!IS_ENABLED(CONFIG_ARCH_HAS_SUPERVISOR_PKEYS) ||
!cpu_feature_enabled(X86_FEATURE_PKS))WARN_ON_ONCE(hw_error_code & X86_PF_PK);Yeah, please stick X86_FEATURE_PKS in disabled-features so you can use cpu_feature_enabled(X86_FEATURE_PKS) by itself here..
done.
thanks, Ira