From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <13426df10909221027u4279cd72hf7b651dfd120339b@mail.gmail.com> References: <13426df10909211129n33481db3gb0ddf024cd67d90a@mail.gmail.com> <13426df10909221027u4279cd72hf7b651dfd120339b@mail.gmail.com> Date: Tue, 22 Sep 2009 11:21:33 -0700 Message-ID: <13426df10909221121g5d203f06qeabf4356940d1193@mail.gmail.com> From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] 9vx (is this the right list)? import issue Topicbox-Message-UUID: 7549d6be-ead5-11e9-9d60-3106f5b1d025 OK, I did this in mntralloc, in the code path in which we reuse the rpc from the mtnalloc.rpcfree: I just simply always allocated a new tag, even if we found an old rpc which was nominally free: I always allocated a new tag, not reusing the old tag. That fixed the problem. So, basically, the way I see it is, grep proc gets an interrupt, kernel will try to flush RPCs which we initiated, we drop the (we think) flushed rpc struct onto the rpcfree list, but the reply from the server is still in flight. We reuse the rpc from rpcfree list, we send out a new T, with the same tag as the previous one which we think we flushed, we get the reply from the earlier RPC, tags match, R does not match T, bad day. This is the same code as is in plan 9. There's harder and harder ways to deal with this, I have some ideas but I expect some of the folks on this list to have better ones. The simplest one that would probably work is to avoid reusing tags quite so quickly. Free tags, yes, but use a counter to indicate "next tag to use", so that it's a relatively long time before a tag for a mount point is reused again. So, e.g., we free tag 3, but the next tag we allocate is tag 4, and so on. Sooner or later we'll use tag 3 again, likely long after any messages in flight have been retired. (weirdly enough, I saw a trick like this used in hardware many years ago ...) That may not be good enough, not sure. It's definitely pretty easy to implement. What I observed is that when this is all working, tag 3 is the only tag ever used! ron