> ... procflushseg finds all processes that share s, sets them all up > to flush their mmu states, and also sets any processor running such a process > to flush its state (that's picked up by a clock interrupt). > > procflushseg will not proceed until all processes and processors that > might need to flush state have done so. (s remains locked throughout.)
Coincidentally, I spent last Sunday debugging a deadlock in precisely this spot. I had absentmindedly tried to use VESA vga on a multiprocessor. The aux/vga -l apparently succeeded and the screen looked great, but as a stealthy side-effect the CPU which had done the VESA call stopped responding to interrupts -- including the local APIC clock interrupt required for the mmu flush as described above. So, some time later when another process (upas/fs as it happens) on the other CPU wanted to adjust a segment size, procflushseg was called and never returned. Debugging can be challenging when cause and effect are minutes or hours apart ...
