On 6/17/21 2:40 PM, Maxim Levitsky wrote:
> On Mon, 2021-06-14 at 18:03 +0200, Philippe Mathieu-Daudé wrote:
>> On 6/11/21 1:46 PM, Philippe Mathieu-Daudé wrote:
>>> When the NVMe block driver was introduced (see commit bdd6a90a9e5,
>>> January 2018), Linux VFIO_IOMMU_MAP_DMA ioctl was only returning
>>> -ENOMEM in case of error. The driver was correctly handling the
>>> error path to recycle its volatile IOVA mappings.
>>>
>>> To fix CVE-2019-3882, Linux commit 492855939bdb ("vfio/type1: Limit
>>> DMA mappings per container", April 2019) added the -ENOSPC error to
>>> signal the user exhausted the DMA mappings available for a container.
>>
>> Hmm this commit has been added before v5.1-rc4.
>>
>> So while this fixes the behavior of v5.1-rc4+ kernels,
>> older kernels using this fix will have the same problem...
>
>
> Hi!
>
> I wonder why not to check for both -ENOMEM and -ENOSPC
> and recycle the mappings in both cases?
>
> I think that would work on both old and new kernels.
>
> What do you think?
Yes, worst case we retry one more time for nothing.
Alex suggested to use VFIO_IOMMU_GET_INFO to get the limit
with VFIO_IOMMU_TYPE1_INFO_DMA_AVAIL, and if not available
the driver should use a reasonable value to limit itself.
I'll try to get it quick, otherwise fall back to your "dual
errno" case.
Thanks both for the ideas,
Phil.
>>> diff --git a/block/nvme.c b/block/nvme.c
>>> index 2b5421e7aa6..12f9dd5cce3 100644
>>> --- a/block/nvme.c
>>> +++ b/block/nvme.c
>>> @@ -1030,7 +1030,7 @@ try_map:
>>> r = qemu_vfio_dma_map(s->vfio,
>>> qiov->iov[i].iov_base,
>>> len, true, &iova);
>>> - if (r == -ENOMEM && retry) {
>>> + if (r == -ENOSPC && retry) {
>>> retry = false;
>>> trace_nvme_dma_flush_queue_wait(s);
>>> if (s->dma_map_count) {
>>>
