From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <692aeda5a7371fbdafc5a64e0eca1975@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Fri, 31 Jul 2009 14:28:42 +0100 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c? Topicbox-Message-UUID: 339964a0-ead5-11e9-9d60-3106f5b1d025 > ... 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 ...