Phillip Susi wrote:
linux-os (Dick Johnson) wrote:
No. Any file I/O, or anything that takes time sleeps and gives up
the CPU, ultimately calling schedule(). That means that anybody
can have its coprocessor state dorked. This has been discussed many
The FPU state is saved across normal thread switches if either the new
or old thread uses the fpu, so this should be safe. Unless this does
not apply to kernel threads?
Wrong. The FPU state is saved if context is switched from one
userspace thread to another. I don't know about kernel threads, but
be aware that lots of the kernel code is not executed in a kernel thread
context, so thread switching details doesn't matter at all.
Driver code is often executed in interrupt context. Any thread can
be interrupted while doing floating-point work, and the floating
point registers are _not_ saved when an interrupt comes in. This
goes for all drivers - disk drivers, usb, serial, audio, video, ...
Drivers may then call all sorts of kernel functions, so the
cpu may have "hot" FPU registers when executing filesystem and VM
code and almost anything else too.
To further complicate this: Your driver can save the FPU registers,
but it too may get interrupted. Possibly even by another instance of
itself, if the user have several devices.
If you divulge the mathematics you need calculated, I'll bet you
will get many answers from responders to the linux-kernel list.
Excellent advice. This problem has been solved so many times already .
Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]