From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E4ACEC433DB for ; Sat, 27 Mar 2021 04:43:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id AB6FA61A18 for ; Sat, 27 Mar 2021 04:43:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230126AbhC0Emf (ORCPT ); Sat, 27 Mar 2021 00:42:35 -0400 Received: from mail-ej1-f49.google.com ([209.85.218.49]:39877 "EHLO mail-ej1-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229611AbhC0Elz (ORCPT ); Sat, 27 Mar 2021 00:41:55 -0400 Received: by mail-ej1-f49.google.com with SMTP id ce10so11421025ejb.6; Fri, 26 Mar 2021 21:41:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rW6IWmw3bAY+7I4axD3cCqiKwmk5Vb6mpW550G67qek=; b=dHAZnch3ODzFGca02JZ+qHhbcvViLtlpiEXEeZsD9Pp2VelbgO+35S0FLpgtUvuTR2 b1GRmFeugGNF+bZYjD88Gi8cWKWn3UPjtTvU9CgKMiMXWuL1cm77Z8UX+Cn+3nBNEI8H XanpMeOqlvQXtOYbiojSM11sDRWo9LmxwqEIIcBMTvSUbUluBuH+qTyF8IOdzbpb62m9 Udxguho6disjdiCYgzf1M21iDNudGUCgaSaPv4wxkisidmcjJNDJAH4iSdfk4NJJSDKC cAi8Q61bV3z0dS8S3hTGrSEn9s8XTyZCmG5yFainyPGr+lDmcLHu761ANG4ZInsbJjys U1ew== X-Gm-Message-State: AOAM533Wq992FyXjANsIoc5DVMcmwWLmZkcvZwIk5og89+WFOXFiKz9h /r/T/jIOibmYe/8ix0KAXkj4dkbupJMz63EDzic= X-Google-Smtp-Source: ABdhPJwchzUeuO7nwhZRNhfFlo0xto2pedUGrvaQ5JsN+Q4JVohbPScXOer60hKq42S2jad7HChK4a5meQdUfRdYvqI= X-Received: by 2002:a17:906:4055:: with SMTP id y21mr18359714ejj.507.1616820114401; Fri, 26 Mar 2021 21:41:54 -0700 (PDT) MIME-Version: 1.0 References: <20210221185637.19281-1-chang.seok.bae@intel.com> <20210221185637.19281-23-chang.seok.bae@intel.com> <871rc9bl3v.fsf@nanos.tec.linutronix.de> <20210326181641.GD27507@zn.tnic> In-Reply-To: <20210326181641.GD27507@zn.tnic> From: Len Brown Date: Sat, 27 Mar 2021 00:41:43 -0400 Message-ID: Subject: Re: [PATCH v4 22/22] x86/fpu/xstate: Introduce boot-parameters to control state component support To: Borislav Petkov Cc: Andy Lutomirski , Thomas Gleixner , "Chang S. Bae" , Ingo Molnar , X86 ML , "Brown, Len" , Dave Hansen , "Liu, Jing2" , "Ravi V. Shankar" , Linux Kernel Mailing List , Linux Documentation List Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 26, 2021 at 2:17 PM Borislav Petkov 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