[PATCH v5] um: Enable preemption in UML

[Johannes Berg]

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?

johannes