[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJvTdKmPBYcSVpZc=hDecOApOy-gWkuT304cS4U37XSjpMH8aw@mail.gmail.com>
Date: Sat, 27 Mar 2021 00:41:43 -0400
From: Len Brown <lenb@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Andy Lutomirski <luto@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
"Chang S. Bae" <chang.seok.bae@...el.com>,
Ingo Molnar <mingo@...nel.org>, X86 ML <x86@...nel.org>,
"Brown, Len" <len.brown@...el.com>,
Dave Hansen <dave.hansen@...el.com>,
"Liu, Jing2" <jing2.liu@...el.com>,
"Ravi V. Shankar" <ravi.v.shankar@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Documentation List <linux-doc@...r.kernel.org>
Subject: Re: [PATCH v4 22/22] x86/fpu/xstate: Introduce boot-parameters to
control state component support
On Fri, Mar 26, 2021 at 2:17 PM Borislav Petkov <bp@...en8.de> wrote:
>
> On Fri, Mar 26, 2021 at 01:53:47PM -0400, Len Brown wrote:
> > At Dave's suggestion, we had a 64 *KB* sanity check on this path.
> > Boris forced us to remove it, because we could not tell him
> > how we chose the number 64.
>
> The only 64 I can remember is
>
> #define XSTATE_BUFFER_MAX_BYTES (64 * 1024)
>
> What does an arbitrary number have to do with signal handling and
> pushing a fat frame on the sigaltstack?
You are right. If that is where the check was, it was the wrong place.
It should be part of that sanity check code where CPUID is parsed.
thanks,
Len Brown, Intel Open Source Technology Center
Powered by blists - more mailing lists