Re: vfio memlock question

[Alex Williamson <alex.williamson@redhat.com>]

Hi Keith,

On Tue, 12 Dec 2023 17:06:39 -0800
Keith Busch <kbusch@kernel.org> wrote:

> I was examining an issue where a user process utilizing vfio is hitting
> the RLIMIT_MEMLOCK limit during a ioctl(VFIO_IOMMU_MAP_DMA) call. The
> amount of memory, though, should have been well below the memlock limit.
> 
> The test maps the same address range to multiple devices. Each time the
> same address range is mapped to another device, the lock count is
> increasing, creating a multiplier on the memory lock accounting, which
> was unexpected to me.
> 
> Another strange thing, the /proc/PID/status shows VmLck is indeed
> increasing toward the limit, but /proc/PID/smaps shows that nothing has
> been locked.
> 
> The mlock() syscall doesn't doubly account for previously locked ranges
> when asked to lock them again, so I was initially expecting the same
> behavior with vfio since they subscribe to the same limit.
> 
> So a few initial questions:
> 
> Is there a reason vfio is doubly accounting for the locked pages for
> each device they're mapped to?
> 
> Is the discrepency on how much memory is locked depending on which
> source I consult expected?

Locked page accounting is at the vfio container level and those
containers are unaware of other containers owned by the same process,
so unfortunately this is expected.  IOMMUFD resolves this by having
multiple IO address spaces within the same iommufd context.

I don't know the reason smaps is not showing what you expect or if it
should.  Thanks,

Alex