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

[Sohil Mehta]

On 8/8/2025 12:49 AM, Oleg Nesterov wrote:
> On 08/08, Lai, Yi wrote:
>>
>> [   17.474769] WARNING: CPU: 1 PID: 731 at arch/x86/kernel/fpu/core.c:61 x86_task_fpu+0x76/0x90
> 
> ...
> 
>> [   17.481244]  xfpregs_get+0x9c/0x1e0
> 
> ...
> 
>> [   17.485304]  do_coredump+0x370e/0x5060
> 

The warning here is mostly benign, right?

x86_task_fpu(target) and x86_task_fpu(current) wouldn't match, causing
sync_fpstate() to return early.

However, independent of this warning, can xfpregs_get()->sync_fpstate()
be called in the context of the PF_USER_WORKER thread? Would that be
problematic?

> Damn, I was going to check the ptrace / coredump paths but didn't have
> time and then forgot :/
> 
> For now, I think we need to remove PF_USER_WORKER from x86_task_fpu().
> Then, we add it back later.
> 

Adding PF_USER_WORKER to the warning is only proposed in this patch so
no harm done yet.

But, I am also skeptical about the x86_task_fpu() warnings. We have
"struct fpu *" comparisons that seem to be getting flagged but should be
valid in principle.

> It is not clear what should we do if debugger does xfpregs_set()...
> 

Yeah, I am wondering whether treating PF_USER_WORKER threads as
equivalent to PF_KTHREAD is truly accurate in the FPU.