2

If Linux softirq is running by interrupting Linux kernel mode and the interrupted task was using FPU it is not allowed to use the FPU in softirq.

If the interrupted task was user mode process it was still allowed to use the FPU in softirq, but not interrupting the kernel mode.

The code in discussion is below.

Question is, Why its so ? 

static inline bool interrupted_kernel_fpu_idle(void)
{
    return !__thread_has_fpu(current) &&
        (read_cr0() & X86_CR0_TS); 
}
Guruswamy Basavaiah
  • 652
  • 4
  • 12

1 Answers1

1

There's only one place to store the FPU state. If kernel mode code you interrupted has already saved the user mode FPU state, then there's no place save the interrupted kernel mode's FPU state.

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
  • "There's only one place to store the FPU state." Where its saved in the kernel ?. As i understand it will be saved in task_struct of the running process. – Guruswamy Basavaiah Aug 04 '14 at 18:21
  • Yes, it will be in the `task_struct`. This answer goes into more detail: http://stackoverflow.com/a/16068179 – Ross Ridge Aug 04 '14 at 18:28
  • Thank you. If we see the above code in question, "interrupted_kernel_fpu_idle". This function check if the interruption has happened for kernel mode. In that case it expected the interrupted kernel thread does not use FPU. Why its so ? Kernel thread should also be able to save the fpu state in the task_struct. – Guruswamy Basavaiah Aug 04 '14 at 18:44
  • The `interrupted_kernel_fpu_idle` function doesn't check to see if the interrupt occurred while executing kernel code. This function is only called when the interrupt didn't occur while executing user mode code. – Ross Ridge Aug 04 '14 at 19:41
  • 1
    It's conceivable for the interrupting routine that wants to use the FPU to do the state save/restore itself - to the currently-running kernel stack. There's several problems with this (nested interrupts and preemption would have to be disabled, and a test might be necessary whether enough space is available on the stack since an entire FPU context is several hundred bytes, but kernel stacks are very small). The overhead of doing that is large - the usecase to benefit from it would have to be ... somewhat special. Special enough that the kernel authors haven't thought it worthwhile. – FrankH. Aug 06 '14 at 21:41