On Donnerstag, 2. Juli 2020 19:23:35 CEST Christian Schoenebeck wrote: > > > Back to the actual topic: so what do we do about the mutex then? CoMutex > > > for 9p2000.u and Mutex for 9p2000.L? I know you find that ugly, but it > > > would just be a transitional measure. > > > > That would ruin my day... > > > > More seriously, the recent fix for a deadlock condition that was present > > for years proves that nobody seems to be using silly clients with QEMU. > > So I think we should just dump the lock and add a one-time warning in > > the top level handlers when we detect a duplicate readdir request on > > the same fid. This should be a very simple patch (I can take care of > > it right away). > > Looks like we have a consensus! Then I wait for your patch removing the > lock, and for your feedback whether or not you see anything else in this > patch set?
Please wait before you work on this patch. I really do think your patch should be based on/after this optimization patch for one reason: if (and even though it's a big if) somebody comes along with a silly client as you named it, then your patch can simply be reverted, which would not be possible if it's next. So I would really suggest I change this patch here to go the ugly way with 2 mutex types for readdir 9p2000.L vs 9p2000.L, and your patch would get rid of that mess by removing the lock entirely, okay? Best regards, Christian Schoenebeck
