From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9ddaa75136b16893053c2f5958d0b064@rei2.9hal> Date: Thu, 23 Aug 2012 01:30:24 +0200 From: cinap_lenrek@gmx.de 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] devmnt crash, fix. Topicbox-Message-UUID: ae2debda-ead7-11e9-9d60-3106f5b1d025 i think we'r seeing exactly what russ described on 9fans here: http://9fans.net/archive/2011/02/358 after we set q->done = 1; (the unlock of m probably doesnt even matter) it might be possible for mountio()'s sleep() call to return immidiately and return, freeing the rpc before mountmux() on another proc/cpu even call wakeup() and potentialy hitting freed memory. if this theory is true (anyone seeing what prevents this from happening?) one trick could be to use a Rendez not embedded in the rpc structure. If we make the Rendez into a Rendez* which we take a local copy of before we set q->done = 1; in mountmux(), and in mountio assign r->r = &up->sleep; (or maybe even dedicate a new Rendez in the proc structure?) then its safe to call wakeup even if the rpc got already freed. This might produce spurious wakeups on that rendez but thats not a big problem (for devmnt's case at least) as we always check rpc->done and repeat the sleep on spurious wakeup. Doing interlocked refcounting to synchronize the wakeup seems like overkill and would me mutch more complicated i think. suggestions? -- cinap