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

[魏桂雄]

> From: "Dave Hansen"<dave.hansen@xxxxxxxxx>
> Date:  Wed, Sep 30, 2026, 00:54
> Subject:  Re: [PATCH] x86/fpu: Free dynamic fpstate on exec()
> To: "Guixiong Wei"<weiguixiong@xxxxxxxxxxxxx>, <x86@xxxxxxxxxx>
> Cc: "Thomas Gleixner"<tglx@xxxxxxxxxx>, "Ingo Molnar"<mingo@xxxxxxxxxx>, "Borislav Petkov"<bp@xxxxxxxxx>, "Dave Hansen"<dave.hansen@xxxxxxxxxxxxxxx>, "H . Peter Anvin"<hpa@xxxxxxxxx>, "Chang S . Bae"<chang.seok.bae@xxxxxxxxx>, <linux-kernel@xxxxxxxxxxxxxxx>, <stable@xxxxxxxxxxxxxxx>
> On 9/29/26 08:10, Guixiong Wei wrote:
> > Preserve the old fpstate pointer across fpstate_reset() and free it only
> > after fpu_reset_fpstate_regs() has invalidated FPU register ownership.
> > This ordering prevents a context switch from saving FPU registers through
> > a freed fpstate pointer.
> 
> Are there any fpstate_reset() paths where this matters?
> 
> I mean, the init task, obviously not. It doesn't have a dynamic fpstate.
> During exec() this reset happens while:
> 
>         bprm->mm = NULL;
> 
> among other things, so I really don't think it's even remotely in the
> context of getting context-switched to.
> 
> For clone(), the destination task is also not in any condition to be
> context-switched to.
> 
> So why defend against context switching? What am I missing?
> 
You are right. Neither existing fpstate_reset() call path needs
to defend against a context switch. I overcomplicated the ordering
rationale and will drop it.

I will move the dynamic fpstate cleanup into fpstate_reset() as you
suggested. It will preserve the old pointer, install and initialize the
embedded fpstate, and then free the old allocation. This makes
fpstate_reset() own the complete state transition.

I will also update the subject and describe the leak.