[PATCH v5] um: Enable preemption in UML

[Anton Ivanov]

On 22/09/2023 10:14, Johannes Berg wrote:
> On Fri, 2023-09-22 at 11:10 +0200, Johannes Berg wrote:
>> On Fri, 2023-09-22 at 10:06 +0100, Anton Ivanov wrote:
>>> On 22/09/2023 09:41, Johannes Berg wrote:
>>>>> Yes, but when does the fork actually happen?
>>>>>
>>>> Looking further at this, now I'm confused as to why it doesn't happen
>>>> _all_ the time.
>>>>
>>>> I think this has pretty much always been wrong, just now we actually
>>>> notice it?
>>>>
>>>> Basically, when we create a new thread (really just mm I think), we say
>>>> the first thing that has to run there is fork_handler(), which
>>>> initialises things the first time around. This calls force_flush_all()
>>>>
>>>> But of course it's called from __schedule(), which has
>>>> preemption/interrupts disabled. So you can't do mmap_read_lock()?
>>>
>>> Stupid question.
>>>
>>> If we have preemption and interrupts disabled and we are UP do we really need to lock it at this point?
>>
>> Heh.
>>
> 
> Ah, but this works:
> 
> --- a/arch/um/kernel/tlb.c
> +++ b/arch/um/kernel/tlb.c
> @@ -606,8 +606,8 @@ void force_flush_all(void)
>   	struct vm_area_struct *vma;
>   	VMA_ITERATOR(vmi, mm, 0);
>   
> -	mmap_read_lock(mm);
> +	rcu_read_lock();
>   	for_each_vma(vmi, vma)
>   		fix_range(mm, vma->vm_start, vma->vm_end, 1);
> -	mmap_read_unlock(mm);
> +	rcu_read_unlock();
>   }
> 
> 
> it seems?
> 
> And it doesn't even seem _bad_ since as you say nothing can change, and
> we only inject stuff into the process in fix_range() anyway.
> 
> So maybe that works - perhaps with a big comment?

Ack. Will add this to the patch and run it through its paces.

> 
> johannes
> 

-- 
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/