[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87r1h7usuf.ffs@nanos.tec.linutronix.de>
Date: Sat, 12 Jun 2021 15:15:36 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>
Cc: Dave Hansen <dave.hansen@...ux.intel.com>,
Fenghua Yu <fenghua.yu@...el.com>,
Tony Luck <tony.luck@...el.com>,
Yu-cheng Yu <yu-cheng.yu@...el.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Borislav Petkov <bp@...e.de>,
Peter Zijlstra <peterz@...radead.org>,
Kan Liang <kan.liang@...ux.intel.com>
Subject: Re: [patch 08/41] x86/fpu: Restrict fpstate sanitizing to legacy components
On Sat, Jun 12 2021 at 00:12, Thomas Gleixner wrote:
> On Fri, Jun 11 2021 at 12:03, Andy Lutomirski wrote:
>> On 6/11/21 9:15 AM, Thomas Gleixner wrote:
>>> + *
>>> + * This is required for the legacy regset functions.
>>> + */
>>> +static void fpstate_sanitize_legacy(struct fpu *fpu)
>>> +{
>>> + struct fxregs_state *fx = &fpu->state.fxsave;
>>> + u64 xfeatures;
>>> +
>>> + if (!use_xsaveopt())
>>> + return;
>>
>> This is confusing, since we never use xsaveopt. It's also wrong -- see
>> above. How about just removing it?
>
> We do and this code is buggy because xsaves does not clear the component
> storage either. Neither does xsavec which we in fact do not use in the
> kernel.
So that kinda works because the CPUs which have XSAVES have XSAVEOPT
too. But XSAVESOPT can be disabled on the command line, which then makes
that condition false...
Oh well.
Powered by blists - more mailing lists