All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Eric Biggers" <ebiggers@kernel.org>
Cc: linux-raid@vger.kernel.org, yukuai@fygo.io
Subject: Re: [PATCH v4 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits
Date: Sat, 15 Aug 2026 18:28:33 +0000	[thread overview]
Message-ID: <20260815182833.F41941F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260815181024.28924-2-ebiggers@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] A malformed CPUID reporting AVX512F=1 but AVX=0 will cause a #GP exception during xsetbv.
--

--- Patch [1]: [PATCH v4 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits ---
commit 7ad6682a0d9e6a99cd138d1dc9dfbd430c1da651
Author: Eric Biggers <ebiggers@kernel.org>

x86/fpu: Check for missing AVX and AVX-512 xstate bits

This patch checks if the CPU declares AVX or AVX-512 support, and verifies
that the corresponding xstate bits are also set. If not, it warns and clears
the CPU capabilities.

> diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c
> index a7b6524a9dea2..97cfd4fb6cc00 100644
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
[ ... ]
> @@ -844,6 +847,24 @@ void __init fpu__init_system_xstate(unsigned int legacy_size)
>  		goto out_disable;
>  	}
>  
> +	mask |= XFEATURE_MASK_YMM;
> +	if (boot_cpu_has(X86_FEATURE_AVX)) {
> +		if ((fpu_kernel_cfg.max_features & mask) != mask) {
> +			pr_err(FW_BUG
> +			       "x86/fpu: Disabling AVX support due to missing xstate features\n");
> +			setup_clear_cpu_cap(X86_FEATURE_AVX);
> +		}
> +	}
> +
> +	mask |= XFEATURE_MASK_AVX512;
> +	if (boot_cpu_has(X86_FEATURE_AVX512F)) {
> +		if ((fpu_kernel_cfg.max_features & mask) != mask) {

[Severity: High]
This is a pre-existing issue, but does this logic handle a malformed CPUID
reporting AVX512F=1 but AVX=0 correctly?

If the xstate leaf reports both YMM and AVX512 support, the AVX validation
block above is skipped because AVX=0. Since mask accumulates both YMM and
AVX512, the check here passes, so X86_FEATURE_AVX512F is not cleared.

Later in fpu__init_system_xstate(), the xsave_cpuid_features loop:

	for (i = 0; i < ARRAY_SIZE(xsave_cpuid_features); i++) {
		unsigned short cid = xsave_cpuid_features[i];

		/* Careful: X86_FEATURE_FPU is 0! */
		if ((i != XFEATURE_FP && !cid) || !boot_cpu_has(cid))
			fpu_kernel_cfg.max_features &= ~BIT_ULL(i);
	}

will clear the YMM bit from max_features because AVX=0, but will retain the
AVX512 bits because AVX512F=1.

Could this result in passing an invalid xstate combination (AVX512 without
YMM) to xsetbv, triggering a #GP exception during boot?

> +			pr_err(FW_BUG
> +			       "x86/fpu: Disabling AVX-512 support due to missing xstate features\n");
> +			setup_clear_cpu_cap(X86_FEATURE_AVX512F);
> +		}
> +	}
> +

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260815181024.28924-1-ebiggers@kernel.org?part=1

  reply	other threads:[~2026-08-15 18:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-15 18:10 [PATCH v4 0/8] x86: Remove cpu_has_xfeatures() and add AVX-512 xor_gen() Eric Biggers
2026-08-15 18:10 ` [PATCH v4 1/8] x86/fpu: Check for missing AVX and AVX-512 xstate bits Eric Biggers
2026-08-15 18:28   ` sashiko-bot [this message]
2026-08-15 18:10 ` [PATCH v4 2/8] um: " Eric Biggers
2026-08-15 18:10 ` [PATCH v4 3/8] crypto: x86 - Stop using cpu_has_xfeatures() Eric Biggers
2026-08-15 18:10 ` [PATCH v4 4/8] lib/crypto: x86: " Eric Biggers
2026-08-15 18:10 ` [PATCH v4 5/8] lib/crc: " Eric Biggers
2026-08-15 18:10 ` [PATCH v4 6/8] x86/fpu: Remove cpu_has_xfeatures() Eric Biggers
2026-08-15 18:10 ` [PATCH v4 7/8] xor: Remove redundant X86_FEATURE_OSXSAVE check Eric Biggers
2026-08-15 18:10 ` [PATCH v4 8/8] xor: Add AVX-512 optimized xor_gen() Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260815182833.F41941F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=ebiggers@kernel.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=yukuai@fygo.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.