[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 06/10] device-core: use atomic_set on .realized property
From: |
Maxim Levitsky |
Subject: |
Re: [PATCH 06/10] device-core: use atomic_set on .realized property |
Date: |
Wed, 30 Sep 2020 21:03:27 +0300 |
User-agent: |
Evolution 3.36.3 (3.36.3-1.fc32) |
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...)
[PATCH 04/10] device_core: use drain_call_rcu in in hmp_device_del/qmp_device_add, Paolo Bonzini, 2020/09/25
[PATCH 09/10] virtio-scsi: use scsi_device_get, Paolo Bonzini, 2020/09/25
[PATCH 10/10] scsi/scsi_bus: fix races in REPORT LUNS, Paolo Bonzini, 2020/09/25
[PATCH 03/10] scsi/scsi_bus: switch search direction in scsi_device_find, Paolo Bonzini, 2020/09/25
Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread, no-reply, 2020/09/25
Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread, no-reply, 2020/09/25
Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread, no-reply, 2020/09/25
Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread, no-reply, 2020/09/25
Re: [PATCH 00/10] Fix scsi devices plug/unplug races w.r.t virtio-scsi iothread, no-reply, 2020/09/25