Re: [9fans] 9vx (is this the right list)? import issue

[ron minnich <rminnich@gmail.com>]

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