On 19/04/2024 14:47, Benjamin Berg wrote:
Hi,
On Wed, 2024-04-03 at 07:27 +0100, anton.iva...@cambridgegreys.com
wrote:
From: Anton Ivanov <anton.iva...@cambridgegreys.com>
1. Preemption requires saving/restoring FPU state. This patch
adds support for it using GCC intrinsics as well as appropriate
storage space in the thread structure. We reuse the space
which is already allocated for the userspace threads in the
thread_info structure.
Do we need to store the FPU state even?
Everybody else does :)
After all, we cannot simply
overwrite userspace FPU registers in UML.
Correct, but you can have kernel threads as well.
Seriously wondering about that. It seems to me it would be sufficient
to ensure that only one kernel task is in a
kern_fpu_begin()/kern_fpu_end() section at any point in time.
So what happens if you have a task which wants fpu and cannot get it at
this point?
Now, I don't know how preempt_disable()/preempt_enable() behaves
exactly. But I would assume it makes such a guarantee and then we can
simply map kern_fpu_begin to preempt_disable and kern_fpu_end to
preempt_enable.
2. irq critical sections need preempt_disable()/preempt_enable().
Yes. Otherwise RAID, crypto, ipsec can mess up things.
3. TLB critical sections need preempt_disable()/preempt_enable().
I think I added those.
4. UML TLB flush is also invoked during a fork. This happens
with interrupts and preempt disabled which disagrees with the
standard mm locking via rwsem. The mm lock for this code path
had to be replaced with an rcu.
Hopefully that flush during fork will be gone soon :-)
Hurrah!!!
Benjamin
[...]
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
