[virtio-comment] Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Sep 18, 2023 at 04:02:54PM +0200, Babis Chalios wrote:
> On 18/9/23 15:58, Michael S. Tsirkin wrote:
> > On Mon, Sep 18, 2023 at 03:00:43PM +0200, Babis Chalios wrote:
> > > > > Right, so I think that there is a race condition between the time the driver
> > > > > sees the used buffers of the first
> > > > > batch and until it adds the second batch on the next leak queue.
> > > > > 
> > > > > 1. driver adds batch 1
> > > > > 2. leak event
> > > > > 3. device uses batch 1
> > > > > 4. driver sees the used buffers and
> > > > >       a. switches leak queues
> > > > >       b. adds batch 2.
> > > > > 5. devices finds initial leak queue empty and sees buffers in second leak
> > > > > queue.
> > > > > 
> > > > > If a second leak event happens after step 3 above and before all of steps 4
> > > > > complete then batch 2 will not
> > > > > be processed as part of the second leak event.
> > > > driver can just pre-add buffers in the second queue.
> > > > 
> > > > 1. available buffers to queue 1-X
> > > > 2. available buffers to queue X
> > > > 
> > > > 
> > > > 3. poll queue X
> > > > 4. used buffers in queue X
> > > > 5. avail buffers in queue X
> > > > 6. poll queue 1-X
> > > > 7. used buffers in queue X
> > > > 8. avail buffers in queue X
> > > > 9. goto 3
> > > > 
> > > Yes, that's what the driver does now in the RFC patch. However, this just
> > > decreases
> > > the race window, it doesn't eliminate it. If a third leak event happens it
> > > might not
> > > find any buffers to use:
> > > 
> > > 1. available buffers to queue 1-X
> > > 2. available buffers to queue X
> > > 
> > > 
> > > 3. poll queue X
> > > 4. used buffers in queue X       <- leak event 1 will use buffers in X
> > > 5. avail buffers in queue X
> > > 6. poll queue 1-X                <- leak event 2 will use buffers in 1-X
> > > 7. used buffers in queue 1-X
> > > 8. avail buffers in queue 1-X
> > >                                   <- leak event 3 (it needs buffers in X, race with step 5)
> > > 9. goto 3
> > 
> > I don't get it. we added buffers in step 5.
> 
> What if the leak event 3 arrives before step 5 had time to actually add the
> buffers in X and make
> them visible to the device?


Then it will see a single event in 1-X instead of two events.  A leak is
a leak though, I don't see does it matter how many triggered.


> 
> > 
> > > 
> > > If, instead, we define a single leak queue and require that VMM should refuse to take a snapshot
> > > if that queue is empty, we avoid the race condition in all cases and IMHO the protocol becomes
> > > much simpler.
> > > 
> > > 
> > > Cheers,
> > > Babis
> > > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> > 


This publicly archived list offers a means to provide input to the
OASIS Virtual I/O Device (VIRTIO) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: virtio-comment-subscribe@lists.oasis-open.org
Unsubscribe: virtio-comment-unsubscribe@lists.oasis-open.org
List help: virtio-comment-help@lists.oasis-open.org
List archive: https://lists.oasis-open.org/archives/virtio-comment/
Feedback License: https://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: https://www.oasis-open.org/policies-guidelines/mailing-lists
Committee: https://www.oasis-open.org/committees/virtio/
Join OASIS: https://www.oasis-open.org/join/