On Mon, 2023-09-25 at 15:27 +0100, Anton Ivanov wrote: > On 25/09/2023 14:33, Johannes Berg wrote: > > On Mon, 2023-09-25 at 14:29 +0100, Anton Ivanov wrote: > > > I have rebased the preempt patch on top of these series. > > > > > > PREEMPT works with some performance decrease. > > > > > > VOLUNTARY deadlocks early in boot around the time it starts loading > > > modules. > > > > > > non-preemptible deadlocks very early in boot. > > > > > > > Well I guess that means there's still some issue in here? Hmm. > > > > Now I don't understand anything anymore, I guess. > > PEBKAC. The tree got corrupted somewhere during rebase. Reapplying everything > on top of a clean master fixed it. > > So it all works.
OK, whew. At least now I no longer _completely_ doubt the mental model I have of UML VM :-) > With some performance penalties compared to the old approach, but works. I still find this odd though, I don't see what the flush would possibly do in a new (mm host) process that's not achievable in arch_dup_mmap()? OK, so let's see - arch_dup_mmap() is _earlier_ than the fork_handler, because that only happens on the very first switch into the process. This is only when it gets scheduled. So we'd be looking for something that copy_process() changes in the MM after copy_mm() and before it can get scheduled? I guess we could even move the flush it into copy_thread(), which is a simpler patch too, but it felt a bit wrong, since that's about the (guest!) process, not the mm. But basically I don't see anything there - fork syscall tail-calls kernel_clone(), which doesn't really do anything with the result of copy_process() except wake it up, and copy_process() doesn't really do anything either? johannes _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um
