From: Paolo Bonzini <pbonzini@redhat•com>
To: Nicholas Piggin <npiggin@gmail•com>,
Aleksandar Markovic <aleksandar.qemu.devel@gmail•com>,
Huacai Chen <chenhuacai@kernel•org>,
Marc Zyngier <maz@kernel•org>, Paul Mackerras <paulus@ozlabs•org>,
David Stevens <stevensd@chromium•org>,
Zhenyu Wang <zhenyuw@linux•intel.com>,
Zhi Wang <zhi.a.wang@intel•com>
Cc: Wanpeng Li <wanpengli@tencent•com>,
kvm@vger•kernel.org, Suzuki K Poulose <suzuki.poulose@arm•com>,
Alexandru Elisei <alexandru.elisei@arm•com>,
intel-gfx@lists•freedesktop.org, linuxppc-dev@lists•ozlabs.org,
linux-kernel@vger•kernel.org, dri-devel@lists•freedesktop.org,
kvmarm@lists•cs.columbia.edu, Will Deacon <will@kernel•org>,
James Morse <james.morse@arm•com>,
kvm-ppc@vger•kernel.org, Sean Christopherson <seanjc@google•com>,
Vitaly Kuznetsov <vkuznets@redhat•com>,
linux-mips@vger•kernel.org, intel-gvt-dev@lists•freedesktop.org,
Joerg Roedel <joro@8bytes•org>,
linux-arm-kernel@lists•infradead.org,
Jim Mattson <jmattson@google•com>
Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn
Date: Thu, 24 Jun 2021 12:21:01 +0200 [thread overview]
Message-ID: <fc2a88ed-6a98-857d-bb1f-73260b01ac30@redhat.com> (raw)
In-Reply-To: <1624529635.75a1ann91v.astroid@bobo.none>
On 24/06/21 12:17, Nicholas Piggin wrote:
>> If all callers were updated that is one thing, but from the changelog
>> it sounds like that would not happen and there would be some gfn_to_pfn
>> users left over.
>>
>> But yes in the end you would either need to make gfn_to_pfn never return
>> a page found via follow_pte, or change all callers to the new way. If
>> the plan is for the latter then I guess that's fine.
>
> Actually in that case anyway I don't see the need -- the existence of
> gfn_to_pfn is enough to know it might be buggy. It can just as easily
> be grepped for as kvm_pfn_page_unwrap.
Sure, but that would leave us with longer function names
(gfn_to_pfn_page* instead of gfn_to_pfn*). So the "safe" use is the one
that looks worse and the unsafe use is the one that looks safe.
> And are gfn_to_page cases also
> vulernable to the same issue?
No, they're just broken for the VM_IO|VM_PFNMAP case.
Paolo
> So I think it could be marked deprecated or something if not everything
> will be converted in the one series, and don't need to touch all that
> arch code with this patch.
next prev parent reply other threads:[~2021-06-24 10:21 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 3:57 [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU David Stevens
2021-06-24 3:57 ` [PATCH 1/6] KVM: x86/mmu: release audited pfns David Stevens
2021-06-24 8:43 ` Nicholas Piggin
2021-06-24 9:43 ` Paolo Bonzini
2021-06-24 15:36 ` Sean Christopherson
2021-06-24 3:57 ` [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn David Stevens
2021-06-24 8:52 ` Nicholas Piggin
2021-06-24 9:42 ` Paolo Bonzini
2021-06-24 9:57 ` Nicholas Piggin
2021-06-24 10:13 ` Paolo Bonzini
2021-06-24 10:17 ` Nicholas Piggin
2021-06-24 10:21 ` Paolo Bonzini [this message]
2021-06-24 10:42 ` Nicholas Piggin
2021-06-24 9:40 ` Marc Zyngier
2021-06-24 3:57 ` [PATCH 3/6] KVM: x86/mmu: avoid struct page in MMU David Stevens
2021-06-24 7:31 ` Paolo Bonzini
2021-06-24 8:58 ` Nicholas Piggin
2021-06-24 10:06 ` Marc Zyngier
2021-06-24 10:17 ` Paolo Bonzini
2021-06-24 10:43 ` Nicholas Piggin
2021-06-24 3:57 ` [PATCH 4/6] KVM: arm64/mmu: " David Stevens
2021-06-24 10:43 ` Marc Zyngier
2021-06-24 3:57 ` [PATCH 5/6] KVM: mmu: remove over-aggressive warnings David Stevens
2021-06-24 3:57 ` [PATCH 6/6] drm/i915/gvt: use gfn_to_pfn's page instead of pfn David Stevens
2021-06-24 4:28 ` David Stevens
2021-06-24 6:57 ` [PATCH 0/6] KVM: Remove uses of struct page from x86 and arm64 MMU Paolo Bonzini
2021-06-24 10:34 ` Nicholas Piggin
2021-06-24 11:42 ` Nicholas Piggin
2021-06-24 12:00 ` Paolo Bonzini
2021-06-24 12:41 ` Paolo Bonzini
2021-06-24 12:57 ` Nicholas Piggin
2021-06-24 15:35 ` Paolo Bonzini
2021-06-25 0:20 ` Nicholas Piggin
2021-06-25 7:44 ` Christian Borntraeger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fc2a88ed-6a98-857d-bb1f-73260b01ac30@redhat.com \
--to=pbonzini@redhat$(echo .)com \
--cc=aleksandar.qemu.devel@gmail$(echo .)com \
--cc=alexandru.elisei@arm$(echo .)com \
--cc=chenhuacai@kernel$(echo .)org \
--cc=dri-devel@lists$(echo .)freedesktop.org \
--cc=intel-gfx@lists$(echo .)freedesktop.org \
--cc=intel-gvt-dev@lists$(echo .)freedesktop.org \
--cc=james.morse@arm$(echo .)com \
--cc=jmattson@google$(echo .)com \
--cc=joro@8bytes$(echo .)org \
--cc=kvm-ppc@vger$(echo .)kernel.org \
--cc=kvm@vger$(echo .)kernel.org \
--cc=kvmarm@lists$(echo .)cs.columbia.edu \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-mips@vger$(echo .)kernel.org \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=maz@kernel$(echo .)org \
--cc=npiggin@gmail$(echo .)com \
--cc=paulus@ozlabs$(echo .)org \
--cc=seanjc@google$(echo .)com \
--cc=stevensd@chromium$(echo .)org \
--cc=suzuki.poulose@arm$(echo .)com \
--cc=vkuznets@redhat$(echo .)com \
--cc=wanpengli@tencent$(echo .)com \
--cc=will@kernel$(echo .)org \
--cc=zhenyuw@linux$(echo .)intel.com \
--cc=zhi.a.wang@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox