[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200507132800.GB23026@zn.tnic>
Date: Thu, 7 May 2020 15:28:00 +0200
From: Borislav Petkov <bp@...en8.de>
To: Yu-cheng Yu <yu-cheng.yu@...el.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Tony Luck <tony.luck@...el.com>,
Andy Lutomirski <luto@...nel.org>,
Rik van Riel <riel@...riel.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Fenghua Yu <fenghua.yu@...el.com>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v3 07/10] x86/fpu/xstate: Update
copy_kernel_to_xregs_err() for XSAVES supervisor states
On Sat, Mar 28, 2020 at 09:43:04AM -0700, Yu-cheng Yu wrote:
> The function copy_kernel_to_xregs_err() uses XRSTOR, which can work with
> standard or compacted format without supervisor xstates. However, when
> supervisor xstates are present, XRSTORS must be used. Fix it by using
> XRSTORS when XSAVES is enabled.
>
> I also considered if there were additional cases where XRSTOR might be
> mistakenly called instead of XRSTORS. There are only three XRSTOR sites
> in kernel:
>
> 1. copy_kernel_to_xregs_booting(), already switches between XRSTOR and
> XRSTORS based on X86_FEATURE_XSAVES.
> 2. copy_user_to_xregs(), which *needs* XRSTOR because it is copying from
> userspace and must never copy supervisor state with XRSTORS.
> 3. copy_kernel_to_xregs_err() mistakenly used XRSTOR only. Fixed in
> this patch.
Avoid having "This patch" or "This commit" in the commit message. It is
tautologically useless.
Also, do
$ git grep 'This patch' Documentation/process
for more details.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists