On Fri, Apr 25, 2014 at 12:09:36PM +0100, Matt Fleming wrote: > Hmm... note that we may call EFI runtime services from interrupt context > in efi_pstore_write(), so it seems like it would be possible to trigger > that WARN_ON_ONCE() there. > > Seiji (Cc'd) might have some opinions on this. > > Either way, if someone sends me a patch ontop of this one that swaps the > __kernel_fpu_begin() for kernel_fpu_begin() I can try them out in my > lab. Well, the more I think about it, the more I'm persuaded that you actually do *really* need that WARN_ON_ONCE check there to make sure you're not fiddling with the FPU while in an interrupt context and in an unsafe way (see interrupted_kernel_fpu_idle() and interrupted_user_mode()). And so you do need the variants without the "__" which include the check. Anyway, here it is, do give it a good run: --- From: Borislav Petkov <bp@xxxxxxx> Date: Fri, 25 Apr 2014 13:30:21 +0200 Subject: [PATCH] efi: Check for unsafe dealing with FPU state in irq ctxt efi_call can happen in an irq context (pstore) and there we really need to make sure we're not scribbling over FPU state while we've interrupted a thread or kernel mode with a live FPU state. Therefore, use the kernel_fpu_begin/end() variants which do that check. Signed-off-by: Borislav Petkov <bp@xxxxxxx> --- arch/x86/include/asm/efi.h | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h index 1eb5f6433ad8..f969ce8bea24 100644 --- a/arch/x86/include/asm/efi.h +++ b/arch/x86/include/asm/efi.h @@ -67,11 +67,9 @@ extern u64 asmlinkage efi_call(void *fp, ...); efi_status_t __s; \ \ efi_sync_low_kernel_mappings(); \ - preempt_disable(); \ - __kernel_fpu_begin(); \ + kernel_fpu_begin(); \ __s = efi_call((void *)efi.systab->runtime->f, __VA_ARGS__); \ - __kernel_fpu_end(); \ - preempt_enable(); \ + kernel_fpu_end(); \ __s; \ }) -- 1.9.0.258.g00eda23 -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|