[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyk=M2XeZd2rBR0hM3NQ5h8r26TgoEOtw4syaOjm3q75A@mail.gmail.com>
Date: Sat, 1 Feb 2014 16:17:26 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: George Spelvin <linux@...izon.com>, Jan Kara <jack@...e.cz>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Maarten Baert <maarten-baert@...mail.com>,
Ingo Molnar <mingo@...nel.org>,
Nate Eldredge <nate@...tsmathematics.com>,
Pekka Riikonen <priikone@....fi>,
Suresh Siddha <sbsiddha@...il.com>,
stable <stable@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [PATCH] Make math_state_restore() save and restore the interrupt flag
On Sat, Feb 1, 2014 at 3:40 PM, H. Peter Anvin <hpa@...or.com> wrote:
>
> OK, let's circle back for a bit. We have an active bug, and we clearly
> have a lot of restructuring that could/should be done. We need to fix
> the bug first; if we're going to a bunch of restructuring then that
> ought to be separate. The first bit is how we fix the immediate bug.
So either of my suggested changes to __kernel_fpu_end() _should_ fix
the bug, with the caveat that if we do take the "check tsk-used-math"
version, we had better verify that yes, we allocate the save storage
before we set that flag. One of the reasons I tended to prefer simpler
the "just do stts()" version is that it seemed safer. I am a bit
worried about the whole interaction with synchronous task state and
interrupts.
Suresh's notion of just always allocating the FP state save area at
process creation would fix it too.
So many ways to fix it, so little knowledge about the actual usage
patterns and performance issues..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists