From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2b1f35826dd59f1276a806174536a4b5@gmx.de> To: 9fans@9fans.net Date: Sat, 30 Aug 2008 04:18:50 +0200 From: cinap_lenrek@gmx.de In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-otbazvkolajclhufdbzthysqyn" Subject: Re: [9fans] notes and traps Topicbox-Message-UUID: 0b597c60-ead4-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-otbazvkolajclhufdbzthysqyn Content-Disposition: inline Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit > > i can reproduce it with this: > > > > http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/ > > > > 8c test.c > > 8a int80.s > > 8l test.8 int80.8 > > ./8.out > > > > 8.out 12490667: suicide: sys: trap: general protection violation > > pc=0x00001333 > > okay. it seems pretty clear from the code that you're dead meat > if you receive a note while you're in the note handler. that is, > up->notified = 1. No! Notes are bufferd in the up->note[] array. If you are in the note handler, another process *can* send you further (NUser) notes without doing any harm. If we are in the note handler (up->notified == 1) and notify() gets hit, it will do nothing and return 0 see: /sys/src/9/pc/trap.c: notify() ... if(n->flag!=NUser && (up->notified || up->notify==0)){ if(n->flag == NDebug) pprint("suicide: %s\n", n->msg); qunlock(&up->debug); pexit(n->msg, n->flag!=NDebug); } if(up->notified){ qunlock(&up->debug); splhi(); return 0; } ... The problem is when we get a NDebug note *after* an NUser note. Then after notify() poped the first NUser note and putting the process into the user handler, the NDebug note will be the next/first (up->note[0]) and then, any (indirect) call to notify() will kill us because now it thinks while handling the last note (up->notified == 1) it caused some trap/fatal event (up->note[0].flag != NUser). but this was *not* the case here! We just traped after some other process put a note in our queue. The notify() code for detecting trap in note handler is fine i think. Whats wrong is that the trap got put after the NUser note. > it looks pretty clear that this is intentional. > i don't see why one couldn't get 3-4 note before the note handler > is called, however. > > given this, calling sleep() from the note handler is an especially > bad idea. > > however, on a multiprocessor (or if you get scheduled by a clock > tick on a up), you're still vulnerable. this is akin to hitting ^c > twice quickly — and watching one's shell exit. > > it would be good to track down what's really going on in your > vm. how many processors does plan 9 think it has? just one :-) > i did some looking to see if i could find any discussions on the > implementation of notes and didn't find anything in my quick scan. > it would be very interesting to have a little perspective from someone > who was there. I have done further experiments and changed postnote() in /sys/src/9/port/proc.c from: ... if(flag != NUser && (p->notify == 0 || p->notified)) p->nnote = 0; ... to: ... if(flag != NUser) p->nnote = 0; ... which lets the testcase run without any suicides. What it does is to ensure (in a harsh way) that not only if the destination process is currently inside the notehandler but always, the trap will end up as the first entry in the up->note array. so no matter what NUser-notes we received before. A trap caused by a note handler will still suicide the process which is correct. This is just a hack. It would be better to keep the other notes and move the tail one step down and then putting the new note on the first entry if its != NUser. What do you think? > - erik -- cinap --upas-otbazvkolajclhufdbzthysqyn 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); 29 Aug 2008 18:31:38 -0000 Received: from gouda.swtch.com (EHLO gouda.swtch.com) [67.207.142.3] by mx0.gmx.net (mx038) with SMTP; 29 Aug 2008 20:31:38 +0200 Received: from localhost ([127.0.0.1] helo=gouda.swtch.com) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from <9fans-bounces@9fans.net>) id 1KZ8gZ-0005gd-Lu; Fri, 29 Aug 2008 18:27:03 +0000 Received: from baron.coraid.com ([12.51.113.4] helo=coraid.com ident=none) by gouda.swtch.com with esmtp (Exim 4.67) (envelope-from ) id 1KZ8gY-0005gY-LE for 9fans@9fans.net; Fri, 29 Aug 2008 18:27:02 +0000 To: 9fans@9fans.net From: erik quanstrom Date: Fri, 29 Aug 2008 14:26:48 -0400 Message-ID: In-Reply-To: <48B7C999.6090109@gmx.de> References: <48B6A660.2080308@gmx.de> <4be02306ffb650f91d3c167024c106b2@coraid.com> <48B7C999.6090109@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] notes and traps X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.9 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: -1 (not scanned, may not use virus scanner) X-GMX-Htest: 0.67 X-GMX-Antispam: 0 (Mail was not recognized as spam) X-GMX-UID: vnKBcA8yYW0/aZs0wmZplBR0amthc5sW > i can reproduce it with this: > > http://cm.bell-labs.com/sources/contrib/cinap_lenrek/traptest/ > > 8c test.c > 8a int80.s > 8l test.8 int80.8 > ./8.out > > 8.out 12490667: suicide: sys: trap: general protection violation > pc=0x00001333 okay. it seems pretty clear from the code that you're dead meat if you receive a note while you're in the note handler. that is, up->notified = 1. it looks pretty clear that this is intentional. i don't see why one couldn't get 3-4 note before the note handler is called, however. given this, calling sleep() from the note handler is an especially bad idea. however, on a multiprocessor (or if you get scheduled by a clock tick on a up), you're still vulnerable. this is akin to hitting ^c twice quickly — and watching one's shell exit. it would be good to track down what's really going on in your vm. how many processors does plan 9 think it has? i did some looking to see if i could find any discussions on the implementation of notes and didn't find anything in my quick scan. it would be very interesting to have a little perspective from someone who was there. - erik --upas-otbazvkolajclhufdbzthysqyn--