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

[Babis Chalios <bchalios@amazon.es>]

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: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org