[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZGTwaP6peRcpl+GA@google.com>
Date: Wed, 17 May 2023 08:19:04 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Yan Zhao <yan.y.zhao@...el.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
alex.williamson@...hat.com, kevin.tian@...el.com, jgg@...dia.com
Subject: Re: [PATCH] vfio/type1: check pfn valid before converting to struct page
On Tue, May 16, 2023, Yan Zhao wrote:
> vfio_pin_page_external() can return a phys_pfn for vma with VM_PFNMAP,
> e.g. for MMIO PFNs.
>
> It's necessary to check if it's a valid pfn before calling pfn_to_page().
>
> Fixes: 34a255e67615 ("vfio: Replace phys_pfn with pages for vfio_pin_pages()")
Might be worth adding a blurb to call out that this is _not_ ABI breakage. Prior
to the buggy commit, KVMGT manually checked that the pfn pinned by vfio_pin_pages()
was pfn_valid(), and s390's driver(s) either blindly expected struct page memory,
e.g. did
ret = page_array_pin(&pa, vdev);
if (ret < 0) {
page_array_unpin_free(&pa, vdev);
return ret;
}
l = n;
for (i = 0; i < pa.pa_nr; i++) {
struct page *page = pfn_to_page(pa.pa_pfn[i]);
void *from = kmap_local_page(page);
or in the case of its crypto driver, apparently was all kinds of confused about
virtual vs. physical, i.e. likely couldn't have worked with anything but "normal"
memory anyways.
AFAICT, those are the only in-tree users of vfio_pin_pages().
Powered by blists - more mailing lists