From: Sean Christopherson <seanjc@google.com>
To: Rick Edgecombe <rick.p.edgecombe@intel.com>
Cc: pbonzini@redhat.com, hao.p.peng@linux.intel.com,
isaku.yamahata@intel.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes
Date: Wed, 13 Mar 2024 12:55:00 -0700 [thread overview]
Message-ID: <ZfIElEiqYxfq2Gz4@google.com> (raw)
In-Reply-To: <20240312173334.2484335-1-rick.p.edgecombe@intel.com>
On Tue, Mar 12, 2024, Rick Edgecombe wrote:
> Fix KVM_SET_MEMORY_ATTRIBUTES to not overflow lpage_info array and trigger
> KASAN splat, as seen in the private_mem_conversions_test selftest.
Ugh, that's embarrassing.
> The issue can be observed simply by compiling the kernel with
> CONFIG_KASAN_VMALLOC and running the selftest “private_mem_conversions_test”,
Ah, less emabarrasing, as KASAN_VMALLOC isn't auto-selected by KASAN=y.
> It is a little ambiguous whether the unaligned tail page should be
Nit, it's the head page, not the tail page. Strictly speaking, it's probably both
(or neither, if you're a half glass empty person), but the buggy code that is
processing regions is specifically dealing with what it calls the head page.
> expected to have KVM_LPAGE_MIXED_FLAG set. It is not functionally
> required, as the unaligned tail pages will already have their
> kvm_lpage_info count incremented. The comments imply not setting it on
> unaligned head pages is intentional, so fix the callers to skip trying to
> set KVM_LPAGE_MIXED_FLAG in this case, and in doing so not call
> hugepage_has_attrs().
> Also rename hugepage_has_attrs() to __slot_hugepage_has_attrs() because it
> is a delicate function that should not be widely used, and only is valid
> for ranges covered by the passed slot.
Eh, I vote to drop the rename. It's (a) a local static, (b) guarded by
CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES=y, (c) pretty obvious from the @slot
param that it works on a single slot, (d) the double underscores suggests
there is an outer wrapper with the same name, which there is not, and (e) the
rename adds noise to a diff that's destined for stable@.
Other than the rename, code looks good.
Thanks!
next prev parent reply other threads:[~2024-03-13 19:55 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-12 17:33 [PATCH] KVM: x86/mmu: x86: Don't overflow lpage_info when checking attributes Rick Edgecombe
2024-03-13 9:49 ` Dongli Zhang
2024-03-13 16:25 ` Edgecombe, Rick P
2024-03-13 21:27 ` Dongli Zhang
2024-03-13 19:55 ` Sean Christopherson [this message]
2024-03-13 20:17 ` Edgecombe, Rick P
2024-03-13 21:11 ` Sean Christopherson
2024-03-13 21:23 ` Edgecombe, Rick P
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=ZfIElEiqYxfq2Gz4@google.com \
--to=seanjc@google.com \
--cc=hao.p.peng@linux.intel.com \
--cc=isaku.yamahata@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=rick.p.edgecombe@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.