[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [PATCH RFC 3/3] rng: leak detection support
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 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]