[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20251029204412.GU760669@ziepe.ca>
Date: Wed, 29 Oct 2025 17:44:12 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Mukesh R <mrathor@...ux.microsoft.com>
Cc: alex.williamson@...hat.com, joe@...ches.com, kvm@...r.kernel.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"wei.liu@...nel.org" <wei.liu@...nel.org>
Subject: Re: [RFC] Making vma_to_pfn() public (due to vm_pgoff change)
On Mon, Oct 27, 2025 at 02:21:56PM -0700, Mukesh R wrote:
> Hi Alex,
>
> This regards vfio passthru support on hyperv running linux as dom0 aka
> root. At a high level, cloud hypervisor uses vfio for set up as usual,
> then maps the mmio ranges via the hyperv linux driver ioctls.
>
> Over a year ago, when working on this I had used vm_pgoff to get the pfn
> for the mmio, that was 5.15 and early 6.x kernels. Now that I am porting
> to 6.18 for upstreaming, I noticed:
>
> commit aac6db75a9fc
> Author: Alex Williamson <alex.williamson@...hat.com>
> vfio/pci: Use unmap_mapping_range()
>
> changed the behavior and vm_pgoff is no longer holding the pfn. In light
> of that, I wondered if the following minor change, making vma_to_pfn()
> public (after renaming it), would be acceptable to you.
No way, no driver should be looking into VMAs like this - it is
already a known security problem.
Is this "hyperv linux driver ioctls" upstream?
You should probably be looking to use the coming DMABUF stuff instead.
Jason
Powered by blists - more mailing lists