mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Guixiong Wei" <weiguixiong@bytedance.com>
To: <x86@kernel.org>
Cc: <tglx@kernel.org>, <mingo@redhat.com>, <bp@alien8.de>,
	 <dave.hansen@linux.intel.com>, <hpa@zytor.com>,
	 <chang.seok.bae@intel.com>, <shuah@kernel.org>,
	 <linux-kernel@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>,  <stable@vger.kernel.org>,
	"Guixiong Wei" <weiguixiong@bytedance.com>
Subject: [PATCH v3 0/2] x86/fpu: Fix dynamic fpstate leak on exec()
Date: Tue, 27 Oct 2026 11:44:28 +0800	[thread overview]
Message-ID: <cover.1793072271.git.weiguixiong@bytedance.com> (raw)

An exec() after using an XFD-controlled xfeature leaks the dynamically
allocated fpstate. Fix the cleanup in fpstate_reset() and add an AMX
regression selftest.

The selftest reports FAIL on an unfixed kernel (verified 10/10 FAILs
on 7.1.3 with the leak reproducer present) and OK with the fix applied.

Changes since v2:
- Free dynamic state at the start of fpstate_reset(), keeping the
  fpstate_free() interface unchanged. Clear the inherited fpstate
  pointer in fpu_clone() before resetting it.
- Replace nested self-exec with a parent fork()/exec() loop.
- Add a pipe-synchronised pre-flight check that confirms the dynamic
  allocation is observable via /proc/vmallocinfo before measuring the
  post-exec() delta. Without that gate "no new entries" is ambiguous
  between "freed" and "never observed" and would silently PASS on
  kernels where the allocation is not reachable. /proc/vmallocinfo is
  the only user-visible signal for a leaked post-exec() fpstate (it
  has no task scope once the task is gone).
- Compare the set of allocation start addresses in /proc/vmallocinfo
  before and after the loop; addresses present only in the "after"
  snapshot count as new allocations that outlived their task. This
  compares allocation identity directly, so unrelated vmalloc churn
  elsewhere does not change the result. SKIP if any matching entry's
  address is hidden (kptr_restrict) because the diff can no longer
  distinguish allocations.
- Report leak failures without preventing subsequent subtests from
  running, and simplify the commit messages.

v2: https://lore.kernel.org/r/cover.1791428412.git.weiguixiong@bytedance.com
v1: https://lore.kernel.org/r/20260929151013.81562-2-weiguixiong@bytedance.com

Guixiong Wei (2):
  x86/fpu: Fix memory leak with dynamic fpstate and exec()
  selftests/x86/amx: Test dynamic fpstate cleanup across exec()

 arch/x86/kernel/fpu/core.c        |   5 +
 tools/testing/selftests/x86/amx.c | 251 +++++++++++++++++++++++++++++-
 2 files changed, 254 insertions(+), 2 deletions(-)


base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
-- 
2.55.0

WARNING: multiple messages have this Message-ID
From: "Guixiong Wei" <weiguixiong@bytedance.com>
To: <x86@kernel.org>
Cc: <tglx@kernel.org>, <mingo@redhat.com>, <bp@alien8.de>,
	 <dave.hansen@linux.intel.com>, <hpa@zytor.com>,
	 <chang.seok.bae@intel.com>, <shuah@kernel.org>,
	 <linux-kernel@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>,  <stable@vger.kernel.org>,
	"Guixiong Wei" <weiguixiong@bytedance.com>
Subject: [PATCH v3 0/2] x86/fpu: Fix dynamic fpstate leak on exec()
Date: Tue, 27 Oct 2026 11:45:25 +0800	[thread overview]
Message-ID: <cover.1793072271.git.weiguixiong@bytedance.com> (raw)
Message-ID: <20261027034525.n_XFdGRdfYdist2-1b1BUKZ4u1Fn2qa1xpUPfMZRII8@z> (raw)

An exec() after using an XFD-controlled xfeature leaks the dynamically
allocated fpstate. Fix the cleanup in fpstate_reset() and add an AMX
regression selftest.

The selftest reports FAIL on an unfixed kernel (verified 10/10 FAILs
on 7.1.3 with the leak reproducer present) and OK with the fix applied.

Changes since v2:
- Free dynamic state at the start of fpstate_reset(), keeping the
  fpstate_free() interface unchanged. Clear the inherited fpstate
  pointer in fpu_clone() before resetting it.
- Replace nested self-exec with a parent fork()/exec() loop.
- Add a pipe-synchronised pre-flight check that confirms the dynamic
  allocation is observable via /proc/vmallocinfo before measuring the
  post-exec() delta. Without that gate "no new entries" is ambiguous
  between "freed" and "never observed" and would silently PASS on
  kernels where the allocation is not reachable. /proc/vmallocinfo is
  the only user-visible signal for a leaked post-exec() fpstate (it
  has no task scope once the task is gone).
- Compare the set of allocation start addresses in /proc/vmallocinfo
  before and after the loop; addresses present only in the "after"
  snapshot count as new allocations that outlived their task. This
  compares allocation identity directly, so unrelated vmalloc churn
  elsewhere does not change the result. SKIP if any matching entry's
  address is hidden (kptr_restrict) because the diff can no longer
  distinguish allocations.
- Report leak failures without preventing subsequent subtests from
  running, and simplify the commit messages.

v2: https://lore.kernel.org/r/cover.1791428412.git.weiguixiong@bytedance.com
v1: https://lore.kernel.org/r/20260929151013.81562-2-weiguixiong@bytedance.com

Guixiong Wei (2):
  x86/fpu: Fix memory leak with dynamic fpstate and exec()
  selftests/x86/amx: Test dynamic fpstate cleanup across exec()

 arch/x86/kernel/fpu/core.c        |   5 +
 tools/testing/selftests/x86/amx.c | 251 +++++++++++++++++++++++++++++-
 2 files changed, 254 insertions(+), 2 deletions(-)


base-commit: 72d3fcf802c45d00b300f25b848a93c3a2bd7c7e
-- 
2.55.0

             reply	other threads:[~2026-10-27  3:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27  3:44 Guixiong Wei [this message]
2026-10-27  3:44 ` [PATCH v3 1/2] x86/fpu: Fix memory leak with dynamic fpstate and exec() Guixiong Wei
2026-10-27  3:45   ` Guixiong Wei
2026-10-27  3:44 ` [PATCH v3 2/2] selftests/x86/amx: Test dynamic fpstate cleanup across exec() Guixiong Wei
2026-10-27  3:45   ` Guixiong Wei
2026-10-27  3:45 ` [PATCH v3 0/2] x86/fpu: Fix dynamic fpstate leak on exec() Guixiong Wei

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=cover.1793072271.git.weiguixiong@bytedance.com \
    --to=weiguixiong@bytedance.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=shuah@kernel.org \
    --cc=stable@vger.kernel.org \
    --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®