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