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
next 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®