Re: [PATCH] x86/fpu: Free dynamic fpstate on exec()

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 9/29/2026 8:10 AM, Guixiong Wei wrote:
> The fpstate embedded in struct fpu only accommodates the default
> xfeatures. When a task first uses a dynamically enabled xfeature,
> fpstate_realloc() installs a larger fpstate allocated with vzalloc().
> 
> fpu_flush_thread() resets fpu->fpstate to the embedded fpstate on exec()
> without freeing the dynamically allocated one. Once the pointer is
> overwritten, arch_release_task_struct() cannot free the allocation when
> the task exits.

Thanks for the finding and fixing this. I see Dave has given good 
suggestions. I think you can follow those into a revision.

...

> On an AMX-capable system, 1000 iterations of requesting XTILEDATA
> permission, executing TILEZERO and calling execve() on the same image
> left 1000 16 KiB allocations attributed to __xfd_enable_feature() in
> /proc/vmallocinfo. None remained after this change.

I would be interested in turning this into a selftest if possible. It 
would be great if you could.

Otherwise, I wrote a case (using XRSTOR instead) and then saw that 
amount from fpstate_relloac() in vmallocinfo:

   Caller/Module                            Difference
   ---------------------------------------------------
   fpstate_realloc.constprop.0 (pages=3)    +16384000
   ...

BTW, just curious if it happens with real-world applications. The 
permission is revoked on exec(), that is a very edge of the TMUL use if 
so. Is it a case running another application right after matrix 
multiplications?

Thanks,
Chang