From: Nicholas Piggin <npiggin@gmail•com>
To: Aleksandar Markovic <aleksandar.qemu.devel@gmail•com>,
Huacai Chen <chenhuacai@kernel•org>,
Marc Zyngier <maz@kernel•org>, Paul Mackerras <paulus@ozlabs•org>,
Paolo Bonzini <pbonzini@redhat•com>,
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 20:42:08 +1000 [thread overview]
Message-ID: <1624531085.fax3fcqpgc.astroid@bobo.none> (raw)
In-Reply-To: <fc2a88ed-6a98-857d-bb1f-73260b01ac30@redhat.com>
Excerpts from Paolo Bonzini's message of June 24, 2021 8:21 pm:
> 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.
The churn isn't justified because of function name length. Choose g2pp()
if you want a non-descriptive but short name.
The existing name isn't good anyway because it not only looks up a pfn
but also a page, and more importantly it gets a ref on the page. The
name should be changed if you introduce a new API.
>> And are gfn_to_page cases also
>> vulernable to the same issue?
>
> No, they're just broken for the VM_IO|VM_PFNMAP case.
No they aren't vulnerable, or they are vunlerable but also broken in
other cases?
Thanks,
Nick
next prev parent reply other threads:[~2021-06-24 10:42 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
2021-06-24 10:42 ` Nicholas Piggin [this message]
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=1624531085.fax3fcqpgc.astroid@bobo.none \
--to=npiggin@gmail$(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=paulus@ozlabs$(echo .)org \
--cc=pbonzini@redhat$(echo .)com \
--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