> I mean that the code as written is assuming that if a read or write > errors out, it can only happen for one of two reasons: > 1) there was an interrupt note, in which case strcmp(error, Eintr) == 0 > 2) there has been an error on the 9P connection, in which case > strcmp(error, Eintr) != 0 and the connection will never work again. > > My suggestion is to enforce #2: if a non-interrupt error happens, > mark the connection so that the kernel won't even try to use it > again. > > Separately, you might investigate what error is happening that > violates the assumption above. In 9vx, it is easy: case #1 happened > but the error was spelled wrong.
how sure are we that 1 holds? couldn't there be other, legitimate and transient errors? could a user-delivered note sneak in and confuse the issue? the problem with my solution is that it could leak tags. i don't see this as a significant problem, but i could be wrong. i think the connection would need to be pretty broken for tags to be leaked. marking connections dead also adds tracking, but in a new place. it could have trouble if ever a transient error happens when strcmp(error, Eintr) == 0, which can happen in 9vx or dt. - erik
