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

[Chang S. Bae]

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