[PATCH v9] um: Enable preemption in UML

[Anton Ivanov]

On 19/04/2024 14:47, Benjamin Berg wrote:
> Hi,
> 
> On Wed, 2024-04-03 at 07:27 +0100, anton.ivanov at cambridgegreys.com
> wrote:
>> From: Anton Ivanov <anton.ivanov at 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/