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
