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



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]