From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Fri, 31 Jul 2009 19:13:47 +0200 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-ggjtxmyartzhxdjhruirasgvhq" Subject: Re: [9fans] Race condition in /sys/src/9/pc/trap.c? Topicbox-Message-UUID: 33a56aca-ead5-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-ggjtxmyartzhxdjhruirasgvhq Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit very interesting. thanks for the sum up. but my testcase crashes a uniprocessor system, so here is no waiting for mmuflushes on other processors going on. any other process that shares the segment and was suspended in the kernel may potentialy hold a pointer to that freed memory area of the segment and may cause a fault in the kernel on resume. process1: in kernel: read(buf) validaddr(buf) ... *context switch* process2: in kernel: ... ibrk() mfreeseg() procflushseg() flushmmu() ... *context switch* process1: still in kernel: memmove(buf, ...) *fault* trap() fault386() fault() => -1 if(!user){ panic() *panic* } ... postnote() we cant really wait for all processes sharing the segment to be in userspace as they may already be waiting in a long blocking syscall. how do we fix this? -- cinap --upas-ggjtxmyartzhxdjhruirasgvhq Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-bounces+cinap_lenrek=gmx.de@9fans.net> X-Flags: 0000 Delivered-To: GMX delivery to cinap_lenrek@gmx.de Received: (qmail invoked by alias); 31 Jul 2009 13:14:34 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx016) with SMTP; 31 Jul 2009 15:14:34 +0200 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 1MWrq6-0002sF-DZ; Fri, 31 Jul 2009 13:08:02 +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 1MWrq4-0002sA-BA for 9fans@9fans.net; Fri, 31 Jul 2009 13:08:00 +0000 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? 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+cinap_lenrek=gmx.de@9fans.net X-GMX-Antivirus: 0 (no virus found) X-GMX-Antispam: 0 (Sender is in whitelist: forsyth@terzarima.net) X-GMX-UID: CJRHIul2ZDI4apF02WY2xj1xemhmY0Eb 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-- --upas-ggjtxmyartzhxdjhruirasgvhq--