From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <8ab5e568a932c69389783454382c2401@terzarima.net> From: Charles Forsyth Date: Fri, 31 Jul 2009 20:31:39 +0100 To: 9fans@9fans.net 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: 33eeaa0a-ead5-11e9-9d60-3106f5b1d025 >but my testcase crashes a uniprocessor system, so here is no >waiting for mmuflushes on other processors going on. it ensures mmuflushes in all other processes (sharing that segment) as well. in fact, the crash you describe just emphasises that point: the page reference no longer exists, hence the fault. the problem (which frankly doesn't bother me) is that fault386 is being overly cautious in assuming that a page fault that occurs in system mode but can't map a page successfully is necessarily a kernel bug: that's not true. it could just note the process instead. (it doesn't bother me because since unix days i've seen less than a handful of programs that SHRINK their existing data segments, and i think that's the only case that can cause the panic you're seeing.)