Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1152343ybl; Tue, 3 Dec 2019 02:35:40 -0800 (PST) X-Google-Smtp-Source: APXvYqyolHKWr7haORtQMPWa/D1hJkiRqnTLWdgBLhHmd/Q8dzmpkxSo1Ohbz/MKhwMQDYZVo7BD X-Received: by 2002:aca:4911:: with SMTP id w17mr1204140oia.22.1575369340622; Tue, 03 Dec 2019 02:35:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1575369340; cv=none; d=google.com; s=arc-20160816; b=g9IEB4hbSYStnsz7ethHaZzk6DlCPtWQxt+MoNMxwtI+hptGxlccuT+YLQySUBLsI3 yMTTILMB0LKhrJkBZo37UggSokqNEBJfmSkenRSJ0DkexXfxGkIKdZrHFTqNo0HJsVJn PlsF8QQorXSswYUCChu7wyK+qebYQNu4B3U/SqZRr2nQudNPLtcXAIy83D58m/4w31Ah KZU1BZRKbLpjBQRkdeNDUU+EhM6qNcGdAQ+kRtIykvuuCqCovi/kwBcWq4WYRWNWS4JW Y1s5W+7yZC882IfwLtb+479u5PfOUi0IH/ZxRH1qxzFEZI7TqH478URvOmYHgmVzg0pF TyLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=T4TjgR5WlZ6mC0MDwenHm8BoUc4Irl2KyZMULtVSlC0=; b=zfnC/tGzlIeHyT4dqfw9rv/JKakU455dQX+LqB07nnKGig6I+p6OV0lJB9t+b62Pkf MWWYzVD81K7rBoCV1T35x+Kyj862QJBp2V0S0iUFXn8A4balcZsoMpVgzGhfGce6oevW WmzGqaStRH/Og4eA9SD2w4bTnvM2xGLKSUuYaaXpo+gRL8UNn4FPHxa4xpqplMKHAAKf cYDyyLrtxKuijSTlero2AsObUlNtdwo/m1kUuOkT5DJ/fb4QpeN+Sx979tBxjz2gvym7 JglxjJvMBieqS7MILfhmiQqiNGJF9ct6kfjFRoorBivnkdMG/NF81QuQn4B8qlU4lEde sKKA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v18si1010202ote.278.2019.12.03.02.35.28; Tue, 03 Dec 2019 02:35:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725954AbfLCKfB (ORCPT + 99 others); Tue, 3 Dec 2019 05:35:01 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:54247 "EHLO Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725773AbfLCKfB (ORCPT ); Tue, 3 Dec 2019 05:35:01 -0500 Received: from bigeasy by Galois.linutronix.de with local (Exim 4.80) (envelope-from ) id 1ic5WB-0008K7-N0; Tue, 03 Dec 2019 11:34:55 +0100 Date: Tue, 3 Dec 2019 11:34:55 +0100 From: Sebastian Andrzej Siewior To: Suravee Suthikulpanit Cc: linux-kernel@vger.kernel.org, x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, jon.grimm@amd.com, Dave Hansen , Thomas Lendacky Subject: Re: [PATCH] x86/fpu: Warn only when CPU-provided sizes less than struct declaration Message-ID: <20191203103455.pvm5jrwkksygmhd7@linutronix.de> References: <1575363688-36727-1-git-send-email-suravee.suthikulpanit@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1575363688-36727-1-git-send-email-suravee.suthikulpanit@amd.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2019-12-03 04:01:28 [-0500], Suravee Suthikulpanit wrote: > The current XCHECK_SZ macro warns if the XFEATURE size reported > by CPUID does not match the size of kernel structure. However, depending > on the hardware implementation, CPUID can report the XSAVE state size > larger than the size of C structures defined for each of the XSAVE state > due to padding. Such case should be safe and should not need to generate > warning message. Do you have an example which CPU generation and which feature? We don't use this these structs in the kernel and the xsave layout is dynamic based on the memory requirements reported by the CPU. But we have a warning which complains about different sizes. Now you change the warning that it is okay if the CPU reports that more memory is needed than we expect. This looks wrong. The other way around would be "okay" but this just renders the warning useless. > Therefore, change the logic to warn only when the CPUID reported size is > less than then size of C structure. > > Fixes: ef78f2a4bf84 ("x86/fpu: Check CPU-provided sizes against struct declarations") > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: Borislav Petkov > Cc: H. Peter Anvin > Cc: Sebastian Andrzej Siewior > Cc: Dave Hansen > Cc: Thomas Lendacky > Signed-off-by: Suravee Suthikulpanit > --- > arch/x86/kernel/fpu/xstate.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c > index e5cb67d..f002115 100644 > --- a/arch/x86/kernel/fpu/xstate.c > +++ b/arch/x86/kernel/fpu/xstate.c > @@ -523,7 +523,7 @@ static void __xstate_dump_leaves(void) > > #define XCHECK_SZ(sz, nr, nr_macro, __struct) do { \ > if ((nr == nr_macro) && \ > - WARN_ONCE(sz != sizeof(__struct), \ > + WARN_ONCE(sz < sizeof(__struct), \ > "%s: struct is %zu bytes, cpu state %d bytes\n", \ > __stringify(nr_macro), sizeof(__struct), sz)) { \ > __xstate_dump_leaves(); \ Sebastian