On Wed, 2020-09-30 at 19:44 +0200, Paolo Bonzini wrote: > On 30/09/20 16:31, Maxim Levitsky wrote: > > > + > > > + qatomic_set(&dev->realized, value); > > > + /* > > > + * Ensure that concurrent users see this update prior to > > > + * any other changes done by unrealize. > > > + */ > > > + smp_wmb(); > > > > I''l probably never fully understand where to use read/write/full barrier. > > If I understand corrctly, read barrier prevents reads done by this thread > > to be reordered, > > by the CPU and write barrier prevents writes done by this CPU to be > > re-ordered. > > I must say that the above is not really satisfactory. The right thing > to do would be to say which changes are done by unrealize; then you > should make sure that *after* reading something that unrealize could > undo you check if dev->realized is still true. I didn't fully understand this to be honest.
I just wanted to explain what I know and what I don't know about hardware barriers. I know that read barriers should be paired with write barriers, like if one CPU has a write barrier, which ensures the orders of writes to two memory locations, the other CPU can then use a read barrier to ensure that it sees those writes in this order. I thus think that reads of dev->realized should be paired with read barrier, but here a full memory barrier isn't really needed. Best regards, Maxim Levitsky > > scsi_device_find is one such case, but I'm not convinced it is enough. > > Paolo > > > Both (depending on the macro) usually imply compiler barrier (to avoid > > compilier re-ordering > > stuff...)