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
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
