We set req->flushreq when walking the work queue holding srv->lock. The original reply is sent while req is still in the work queue, thus there is a race where flushreq could be set just after the postprocess function tests it and the reply discarded. Defer the flushreq reply until after the req has been removed from the work queue.
Just chased down a double-close problem and this would have helped. Should never happen unless something is wrong with file descriptor accounting.
These operations, if successfully flushed, need to be undone with regard to fid accounting at least. See Tflush(9p)
v9fs does not currently handle a flushed Tclunk/Tremove properly. It should behave as though these ops were never sent, meaning the fid remains valid and cannot be reused. However it unconditionally frees them internally. This must be fixed, however it is ueful to be able to interoperate with older clients, so we create this workaround and enable it by default.
Also, further improvements reducing the race between clunked walk/clunk/remove and walk newfid. Introduce the a blocking version of np_fid_create that makes the server tolerant of either ordering of flush response and flushed request retirement, with fid accounting.