On Fri, 23 Jul 2021 12:56:15 +0200 Paolo Bonzini wrote: >On 23/07/21 11:48, Hillf Danton wrote: >> What the comment does not cover is the cases of more-than-two-party race. > >But, you still haven't explained what's the bug there. I am inclined to calling it race that has been there before and after the big comment was added, instead of bug. CPU1 CPU2 CPU3 CPU4 ---- ---- ---- ---- lock WQ count += n no waiter unlock WQ ------------------------------- c0 = count lock WQ ------------------------------- c2 = count add waiter for EPOLLIN unlock WQ lock WQ count = 0 wakeup EPOLLOUT unlock WQ lock WQ count += n no waiter unlock WQ ------------------------------- c1 = count The c0 and c1 in the above chart are what I proposed, while c2 falls under the range covered by the seep in the comment, * The read _can_ therefore seep into add_wait_queue's critical * section, but cannot move above it! add_wait_queue's spin_lock acts * as an acquire barrier and ensures that the read be ordered properly * against the writes. and is likely different to c1.
