From: Sean Christopherson <seanjc@google.com>
To: Andrew Jones <ajones@ventanamicro.com>
Cc: Markus Elfring <Markus.Elfring@web.de>,
Kunwu Chan <chentao@kylinos.cn>,
linux-kselftest@vger.kernel.org, kvm@vger.kernel.org,
kernel-janitors@vger.kernel.org,
Muhammad Usama Anjum <usama.anjum@collabora.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Shuah Khan <shuah@kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
Kunwu Chan <kunwu.chan@hotmail.com>,
Anup Patel <anup@brainfault.org>, Thomas Huth <thuth@redhat.com>,
Oliver Upton <oliver.upton@linux.dev>
Subject: Re: [PATCH] KVM: selftests: Add 'malloc' failure check in test_vmx_nested_state
Date: Tue, 23 Apr 2024 12:15:47 -0700 [thread overview]
Message-ID: <ZigI48_cI7Twb9gD@google.com> (raw)
In-Reply-To: <20240423-0db9024011213dcffe815c5c@orel>
On Tue, Apr 23, 2024, Andrew Jones wrote:
> On Tue, Apr 23, 2024 at 07:56:01AM -0700, Sean Christopherson wrote:
> > +others
> >
> > On Tue, Apr 23, 2024, Markus Elfring wrote:
> > > …
> > > > This patch will add the malloc failure checking
> > > …
> > >
> > > * Please use a corresponding imperative wording for the change description.
> > >
> > > * Would you like to add the tag “Fixes” accordingly?
> >
> > Nah, don't bother with Fixes. OOM will cause the test to fail regardless, the
> > fact that it gets an assert instead a NULL pointer deref is nice to have, but by
> > no means does it fix a bug.
> >
> > > > +++ b/tools/testing/selftests/kvm/x86_64/vmx_set_nested_state_test.c
> > > > @@ -91,6 +91,7 @@ void test_vmx_nested_state(struct kvm_vcpu *vcpu)
> > > > const int state_sz = sizeof(struct kvm_nested_state) + getpagesize();
> > > > struct kvm_nested_state *state =
> > > > (struct kvm_nested_state *)malloc(state_sz);
> > > > + TEST_ASSERT(state, "-ENOMEM when allocating kvm state");
> > > …
> > >
> > > Can “errno” be relevant for the error message construction?
> >
> > Probably not, but there's also no reason to assume ENOMEM. TEST_ASSERT() spits
> > out the actual errno, and we can just say something like "malloc() failed for
> > blah blah blah".
> >
> > But rather than keeping playing whack-a-mole, what if we add macros to perform
> > allocations and assert on the result? I have zero interest in chasing down all
> > of the "unsafe" allocations, and odds are very good that we'll collectively fail
> > to enforce checking on new code.
> >
> > E.g. something like (obviously won't compile, just for demonstration purposes)
> >
> > #define kvm_malloc(x)
> > ({
> > void *__ret;
> >
> > __ret = malloc(x);
> > TEST_ASSERT(__ret, "Failed malloc(" #x ")\n");
> > __ret;
> > })
> >
> > #define kvm_calloc(x, y)
> > ({
> > void *__ret;
> >
> > __ret = calloc(x, y);
> > TEST_ASSERT(__ret, "Failed calloc(" #x ", " #y ")\n");
> > __ret;
> > })
>
> Sounds good to me, but I'd call them test_malloc, test_calloc, etc. and
> put them in include/test_util.h
Possibly terrible idea: what if we used kmalloc() and kcalloc()? K is for KVM :-)
I like test_* more than kvm_*, but I'm mildly concerned that readers will be
confused by "test", e.g. initially thinking the "test" means it's just "testing"
if allocation is possible.
The obvious counter-argument is that people might also get tripped by kmalloc(),
e.g. thinking that selftests is somehow doing a kernel allocation.
I almost wonder if we should just pick a prefix that's less obviously connected
to KVM and/or selftests, but unique and short.
Hmm, tmalloc(), i.e t[est]malloc()? tcalloc() gets a bit close to Google's
TCMalloc[*], but I suspect that any confusion would be entirely limited to
Googlers, and I'll volunteer us to suck it up and deal with it :-)
[*] https://github.com/google/tcmalloc
next prev parent reply other threads:[~2024-04-23 19:15 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-23 7:39 [PATCH] KVM: selftests: Add 'malloc' failure check in test_vmx_nested_state Kunwu Chan
2024-04-23 8:49 ` Muhammad Usama Anjum
2024-04-23 10:45 ` Markus Elfring
2024-04-23 14:56 ` Sean Christopherson
2024-04-23 15:14 ` Andrew Jones
2024-04-23 19:15 ` Sean Christopherson [this message]
2024-04-24 2:59 ` Kunwu Chan
2024-04-24 5:41 ` Dan Carpenter
2024-04-24 14:47 ` Sean Christopherson
2024-04-24 7:50 ` Andrew Jones
2024-04-24 14:51 ` Sean Christopherson
2024-04-24 17:18 ` Oliver Upton
2024-04-25 16:25 ` Sean Christopherson
2024-05-10 8:40 ` Kunwu Chan
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=ZigI48_cI7Twb9gD@google.com \
--to=seanjc@google.com \
--cc=Markus.Elfring@web.de \
--cc=ajones@ventanamicro.com \
--cc=anup@brainfault.org \
--cc=chentao@kylinos.cn \
--cc=kernel-janitors@vger.kernel.org \
--cc=kunwu.chan@hotmail.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=thuth@redhat.com \
--cc=usama.anjum@collabora.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.