From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: Charles Forsyth Date: Fri, 31 Jul 2009 14:07:28 +0100 To: 9fans@9fans.net In-Reply-To: <1a242b28f6d149aec599a1175df52718@terzarima.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-iwwzwwnktsnpqubxywokowbrfy" Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c? Topicbox-Message-UUID: 33875ac6-ead5-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-iwwzwwnktsnpqubxywokowbrfy Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit this resulted in a little side discussion. to save someone else from having to break a strong oath about 9fans, i'll sum it up. the existing code handles this situation. when several processes share a segment, and any one of them decides to shrink the segment, all the processes must see the change before the pages are made available for re-use. any one of them could have any of those pages currently in their mmu state. and any must be removed from the mmu state local to the process, to ensure that no further access to the pages is possible before they are freed. the critical point is that it's irrelevant whether traps or syscalls are involved: ordinary store instructions are clearly bad enough. thus /sys/src/9/port/segment.c:/^mfreeseg contains (with s locked) /* flush this seg in all other processes */ if(s->ref > 1) procflushseg(s); and 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.) after the flush, no process or processor can have a reference to any of the pages in its mmu state. it is safe to free them, which mfreeseg does. now, a process might still be executing a system call or some other trap that might refer to that segment, to an address that's now been removed by another process. to access the memory, it must ultimately issue a load or a store instruction (even for syscalls, such as read or write). that instruction will trap, because as described above there is no longer a valid mmu mapping for that address within the process. normally, the trap will find the right page in the software mmu structures and install the map. in this case, however, it can't find the address, so it will raise an exception in the process (ie, send a note). (all such searches are done with the segment properly locked.) --upas-iwwzwwnktsnpqubxywokowbrfy Content-Type: message/rfc822 Content-Disposition: inline Received: from gouda.swtch.com ([67.207.142.3]) by lavoro; Thu Jul 30 16:55:14 BST 2009 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from <9fans-bounces@9fans.net>) id 1MWXy0-0005DO-Fu; Thu, 30 Jul 2009 15:54:52 +0000 Received: from cpc1-york4-2-0-cust436.7-1.cable.virginmedia.com ([80.2.115.181] helo=smtp.terzarima.net ident=none) by gouda.swtch.com with esmtp (Exim 4.69) (envelope-from ) id 1MWXxz-0005DJ-1n for 9fans@9fans.net; Thu, 30 Jul 2009 15:54:51 +0000 Message-ID: <1a242b28f6d149aec599a1175df52718@terzarima.net> From: Charles Forsyth Date: Thu, 30 Jul 2009 16:54:16 +0100 To: 9fans@9fans.net In-Reply-To: <5aa659e960616a9536ee55194b02c767@gmx.de> 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? X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.10 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces+forsyth=terzarima.net@9fans.net just stop processes with s->ref > 1 from freeing parts of s with ibrk. it's not as if anything ever does in practice. --upas-iwwzwwnktsnpqubxywokowbrfy--