Re: [PATCH] block/nvme: Fix VFIO_MAP_DMA failed: No space left on device

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

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) {
>>>