Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754683AbaBATqR (ORCPT ); Sat, 1 Feb 2014 14:46:17 -0500 Received: from mail-ve0-f175.google.com ([209.85.128.175]:54497 "EHLO mail-ve0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752873AbaBATqQ (ORCPT ); Sat, 1 Feb 2014 14:46:16 -0500 MIME-Version: 1.0 In-Reply-To: <52ED4C96.6020703@zytor.com> References: <52ED4C96.6020703@zytor.com> Date: Sat, 1 Feb 2014 11:46:15 -0800 X-Google-Sender-Auth: QMXkG1Ug3WUYM-hGi-0jKGsnINg Message-ID: Subject: Re: [PATCH] Make math_state_restore() save and restore the interrupt flag From: Linus Torvalds To: "H. Peter Anvin" Cc: Suresh Siddha , Nate Eldredge , Thomas Gleixner , Ingo Molnar , "the arch/x86 maintainers" , stable , Linux Kernel Mailing List , Maarten Baert , Jan Kara , George Spelvin , Pekka Riikonen Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 1, 2014 at 11:35 AM, H. Peter Anvin wrote: > > This will obviously not protect eageronly features (MPX, LWP, ...) so this > means those features are permanently unavailable to the kernel, even inside > kernel_fpu_begin/end. Now, currently I don't think we have any plans to use > those in the kernel (at least not in a way where kernel_fpu_begin/end makes > sense as bracketing), but it is something worth keeping in mind. Hmm. If there are features that (silently) depend on the FPU state being on, then the plain "stts" doesn't work at all, because we'd be returning to user space too (not just kernel space) with TS turned off. .. which *does* actually bring up something that might work, and might be a good idea: remove the "restore math state or set TS" from the normal kernel paths *entirely*, and move it to the "return to user space" phase. We could do that with the whole "task_work" thing (or perhaps just do_notify_resume(), especially after merging the "don't necessarily return with iret" patch I sent out earlier), with additionally making sure that scheduling does the right thing wrt a "currently dirty math state due to kernel use". The advantage of that would be that we really could do a *lot* of FP math very cheaply in the kernel, because we'd pay the overhead of kernel_fpu_begin/end() just once (well, the "end" part would be just setting the bit that we now have dirty state, the cost would be in the return-to-user-space-and-restore-fp-state part). Comments? That would be much more invasive than just changing __kernel_fpu_end(), but would bring in possibly quite noticeable advantages under loads that use the FP/vector resources in the kernel. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/