mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Andrei Vagin <avagin@google.com>,
	Thomas Gleixner <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>
Cc: <linux-kernel@vger.kernel.org>, <criu@lists.linux.dev>,
	Dave Hansen <dave.hansen@linux.intel.com>, <x86@kernel.org>,
	Alexander Mikhalitsyn <alexander@mihalicyn.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 7/7] selftests/x86: Add tests for signal frame FPU portability
Date: Mon, 14 Sep 2026 10:03:28 -0700	[thread overview]
Message-ID: <2abe67d3-05d9-4c68-b379-53445df7e7a1@intel.com> (raw)
In-Reply-To: <20260908043427.1842515-8-avagin@google.com>

On 9/7/2026 9:34 PM, Andrei Vagin wrote:
> Add a new selftest tools/testing/selftests/x86/sigframe_fpu_portability.c
> to verify signal frame portability and consistency when the xstate size
> is shrunk:
> 
> - test_valid_shrunk_xstate_size: Verifies that the kernel correctly
>    restores the xstate context from a signal frame where xstate_size has
>    been manually shrunk to only cover active features, as long as the
>    FP_XSTATE_MAGIC2 marker is correctly placed. This simulates migrating
>    a process created on a host with fewer xstate features to a host with
>    more features.
> 
> - test_invalid_shrunk_xstate_size: Verifies that the kernel rejects
>    (via SIGSEGV) a signal frame where xstate_size is smaller than required
>    by the enabled features in the xfeatures mask.
> 
> Reviewed-by: Alexander Mikhalitsyn <alexander@mihalicyn.com>
> Signed-off-by: Andrei Vagin <avagin@google.com>

...


> +static void sig_print(const char *msg)
> +{
> +	int left = SIGNAL_BUF_LEN - strlen(sig_err_buf) - 1;
> +
> +	strncat(sig_err_buf, msg, left);
> +}
> +
> +

Nit: extra empty line


> +static void __handle_shrunk_xstate_size(int sig, siginfo_t *si, void *ucp, bool valid_size)
> +{
> +	ucontext_t *uc = ucp;
> +	void *fp = uc->uc_mcontext.fpregs;
> +	struct _fpx_sw_bytes *sw;
> +	struct xsave_buffer *xbuf;
> +	uint64_t xfeatures, *ymmh_p;
> +
> +	if (!fp) {
> +		sig_print("fpregs is NULL\n");
> +		return;
> +	}
> +
> +	sw = get_fpx_sw_bytes(fp);
> +	if (sw->magic1 != FP_XSTATE_MAGIC1) {
> +		sig_print("magic1 is not valid\n");
> +		return;
> +	}
> +
> +	xbuf = (struct xsave_buffer *)fp;
> +
> +	/*
> +	 * Both test cases shrink the frame to contain only AVX (FP + SSE + YMM).
> +	 * If valid_size is true, set xstate_size to match the enabled features.
> +	 * If valid_size is false, set xstate_size too small (SSE only), which
> +	 * the kernel must reject.
> +	 */
> +	if (valid_size)
> +		sw->xstate_size = xstate_size_ymm;
> +	else
> +		sw->xstate_size = XSTATE_SSE_ONLY_SIZE;
Yeah, I think this note explains the distinction between the two test 
cases and the point of testing:

   Reviewed-by: Chang S. Bae <chang.seok.bae@intel.com>

Thanks,
Chang

  reply	other threads:[~2026-09-14 17:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-08  4:34 [PATCH v5 0/7] x86/fpu: Restore and reinforce signal frame portability Andrei Vagin
2026-09-08  4:34 ` [PATCH 1/7] x86/fpu: Document signal frame layout and portability Andrei Vagin
2026-09-16  4:53   ` Borislav Petkov
2026-09-08  4:34 ` [PATCH 2/7] x86/fpu: Clean up and rename variables in signal frame handling Andrei Vagin
2026-09-08  4:34 ` [PATCH 3/7] x86/fpu: Extract restore_from_ia32_fxstate() and clean up fpu__restore_sig() Andrei Vagin
2026-09-14 17:00   ` Chang S. Bae
2026-09-08  4:34 ` [PATCH 4/7] x86/fpu: Document reasoning of FX-only fallback Andrei Vagin
2026-09-08  4:34 ` [PATCH 5/7] x86/fpu: Fix potential underflow in xstate_calculate_size() Andrei Vagin
2026-09-08  4:34 ` [PATCH 6/7] x86/fpu: Pre-fault only required size of xstate buffer Andrei Vagin
2026-09-08  4:34 ` [PATCH 7/7] selftests/x86: Add tests for signal frame FPU portability Andrei Vagin
2026-09-14 17:03   ` Chang S. Bae [this message]
2026-09-14 17:05 ` [PATCH v5 0/7] x86/fpu: Restore and reinforce signal frame portability Chang S. Bae

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=2abe67d3-05d9-4c68-b379-53445df7e7a1@intel.com \
    --to=chang.seok.bae@intel.com \
    --cc=alexander@mihalicyn.com \
    --cc=avagin@google.com \
    --cc=bp@alien8.de \
    --cc=criu@lists.linux.dev \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®