[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87871e60-4e64-2355-11b4-6201cab8bf75@intel.com>
Date: Fri, 26 Apr 2019 13:44:14 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, jannh@...gle.com,
riel@...riel.com, mingo@...hat.com, bp@...e.de, Jason@...c4.com,
luto@...nel.org, tglx@...utronix.de, rkrcmar@...hat.com,
mingo@...nel.org, hpa@...or.com, kvm@...r.kernel.org,
pbonzini@...hat.com, kurt.kanzenbach@...utronix.de
Subject: Re: [RFC PATCH] x86/fpu: Don't unconditionally add
XFEATURE_MASK_FPSSE on sigentry
On 4/26/19 1:05 PM, Sebastian Andrzej Siewior wrote:
>
> copy_fpstate_to_sigframe()
> |
> copy_fpregs_to_sigframe() fails.
> |
> using_compacted_format()
Aw, crud. I was looking at Linus's tree. Sorry about that. In Linus's
tree, if copy_fpregs_to_sigframe() fails, we just return from
copy_fpstate_to_sigframe() immediately. In other words, either XSAVE
works, and we don't have this issue, or XSAVE fails and we don't do the
fixup code in question.
I'll say it again, though: I think we should be using the XSAVE
instruction to save this state. If we need to map some pages in order
to make XSAVE work, then I think we should bring some pages in and we
can do *that* in the slow path. We can even do that without taking page
faults by just calling get_user_pages() for instance.
Or, the slow path could be to fpregs_unlock(), zero the user area
(taking and handling page faults), then fpregs_lock() and retry the
copy_fpregs_to_sigframe().
Powered by blists - more mailing lists