From: Sean Christopherson <seanjc@google.com>
To: sashiko-reviews@lists.linux.dev
Cc: kvm@vger.kernel.org
Subject: Re: [PATCH] KVM: selftests: Make guest_snprintf() a macro and use it as appropriate
Date: Tue, 29 Sep 2026 18:18:53 -0700 [thread overview]
Message-ID: <arxjfYTdZyM2HejW@google.com> (raw)
In-Reply-To: <20260930002238.649421F000FF@smtp.kernel.org>
On Wed, Sep 30, 2026, sashiko-bot@kernel.org wrote:
> Closes: https://lore.kernel.org/all/20260918113631.634233-4-gokul02k@gmail.com
>
> > diff --git a/tools/testing/selftests/kvm/include/test_util.h b/tools/testing/selftests/kvm/include/test_util.h
> > index a6a3e16578959..817d4d5ca7cc7 100644
> > --- a/tools/testing/selftests/kvm/include/test_util.h
> > +++ b/tools/testing/selftests/kvm/include/test_util.h
> > @@ -238,7 +238,17 @@ static inline u32 atoi_non_negative(const char *name, const char *num_str)
> > }
> >
> > int guest_vsnprintf(char *buf, int n, const char *fmt, va_list args);
> > -__printf(3, 4) int guest_snprintf(char *buf, int n, const char *fmt, ...);
> > +
> > +#define guest_snprintf(__buf, __n, __fmt) \
> > +({ \
> > + va_list va; \
> > + int len; \
>
> [Severity: Medium]
> Does this macro shadow caller arguments? If a caller passes an argument
> named len to guest_snprintf(), it will be shadowed by the uninitialized
> local len due to C scoping rules for statement expressions. The inner len
> is then passed to guest_vsnprintf(), which could result in a random or
> uninitialized buffer size.
>
> > + \
> > + va_start(va, __fmt); \
>
> [Severity: Medium]
> Does this implicitly capture the caller's variadic arguments?
>
> The macro internally invokes va_start(va, __fmt), which couples it to the
> caller's stack frame. If this macro is used in a non-variadic function,
> or if __fmt is not the rightmost named argument of the calling function,
> could va_start cause undefined behavior?
Ugh, and now I remember why we ended up with duplicate code. Lame. I'll drop
this and grab Gokul's original patch. As much as I want to keep guest_snprintf()
around "just in case", in practice I highly doubt we'll ever use it.
prev parent reply other threads:[~2026-09-30 1:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 0:13 [PATCH] KVM: selftests: Make guest_snprintf() a macro and use it as appropriate Sean Christopherson
2026-09-30 0:22 ` sashiko-bot
2026-09-30 1:18 ` Sean Christopherson [this message]
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=arxjfYTdZyM2HejW@google.com \
--to=seanjc@google.com \
--cc=kvm@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.