Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support
Babis Chalios <[email protected]>
| Newsgroups | dev.linux.lists.virtio-dev |
|---|---|
| Message-ID | <[email protected]> |
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? > >> >> 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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]