On Tue, Dec 20, 2022 at 07:15:00PM -0500, Joel Fernandes wrote: > On Tue, Dec 20, 2022 at 5:45 PM Frederic Weisbecker <frederic@xxxxxxxxxx> wrote: > Agreed about (1). > > > _ In (2), E pairs with the address-dependency between idx and lock_count. > > But that is not the only reason. If that was the only reason for (2), > then there is an smp_mb() just before the next-scan post-flip before > the lock counts are read. The post-flip barrier makes sure the new idx is visible on the next READER's turn, but it doesn't protect against the fact that "READ idx then WRITE lock[idx]" may appear unordered from the update side POV if there is no barrier between the scan and the flip. If you remove the smp_mb() from the litmus test I sent, things explode.
