Re: [PATCH v3 2/2] x86/fpu: Update the debug flow for x86_task_fpu()

[Sohil Mehta]

On 8/12/2025 5:57 AM, Oleg Nesterov wrote:

> A PF_USER_WORKER can't initiate the coredump, it blocks all signals except
> SIGKILL and SIGSTOP. But this doesn't really matter.
> 

Thanks for checking.

> First of all, I think that in the long term kthreads and PF_USER_WORKERs
> should run without "struct fpu" attached to task_struct, so x86_task_fpu()
> should return NULL regardless of CONFIG_X86_DEBUG_FPU in this case. 

Having x86_task_fpu() to be consistent would definitely reduce the
number of corner cases we have to deal with :)

"struct fpu" seems to hold some metadata such as avx512_timestamp as
well as some permissions. Hopefully we never need any of that for
PF_USER_WORKERs.

Is the eventual goal of running without "struct fpu" to save memory or
having a cleaner implementation?

> So. The problem is that do_coredump() paths or ptrace can abuse
> PF_USER_WORKER's FPU state for no reason.
> 

Agreed, this requires immediate solving.

> To simplify, lets only discuss REGSET64_FP for now. As for xfpregs_get(),
> everything looks simple, but needs some preparatory patches. membuf_write()
> and copy_xstate_to_uabi_buf() should use &init_fpstate instead of
> x86_task_fpu(target)->fpstate when target->flags & PF_USER_WORKER. This
> matches the reality.
> 

Yeah, using init_fpstate seems reasonable. I don't know what userspace
would do with that information though. But, not returning anything would
likely break some debugging flows.

> But what about xfpregs_set() ? Can it simply return, say, -EPERM ?
> 

This would modify legacy behavior, but I don't think changing the
register values would have any effect either, right? Another option is
to silently ignore the set(). Maybe we can go with your approach unless
someone complains.

> What do you think?
> 

My knowledge about the FPU handling is fairly limited. So I don't have a
strong opinion on this. Just curiosity and questions! :)

Sohil