Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Amit Machhiwal <amachhiw@linux.ibm.com>
To: Gautam Menghani <gautam@linux.ibm.com>
Cc: Amit Machhiwal <amachhiw@linux.ibm.com>,
	Harsh Prateek Bora <harshpb@linux.ibm.com>,
	qemu-ppc@nongnu.org, Vaibhav Jain <vaibhav@linux.ibm.com>,
	Chinmay Rath <rathc@linux.ibm.com>,
	Glenn Miles <milesg@linux.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Nicholas Piggin <npiggin@gmail.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [PATCH] target/ppc/kvm: Fix const violation when trimming CPU alias suffix
Date: Fri, 8 May 2026 11:27:59 +0530	[thread overview]
Message-ID: <20260508110407.6eeeb01e-d6-amachhiw@linux.ibm.com> (raw)
In-Reply-To: <af1ynfIuksZKDFau@Gautams-MacBook-Pro.local>

Hi Gautam,

Thanks for taking a look. Please find my response inline below:

On 2026/05/08 10:50 AM, Gautam Menghani wrote:
> On Mon, May 04, 2026 at 07:13:44PM +0530, Amit Machhiwal wrote:
> > GCC 16 tightens diagnostics around const correctness and now correctly
> > rejects attempts to modify strings referenced through const-qualified
> > pointers. In kvm_ppc_register_host_cpu_type(), ppc_cpu_aliases[i].model
> > is defined as const char *, but the code was using strstr() on it and
> > then modifying the returned pointer in-place to strip
> > POWERPC_CPU_TYPE_SUFFIX.
> > 
> > This results in a write through a pointer derived from const data,
> > triggering a build failure with GCC 16:
> > 
> >   error: assignment discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
> >         suffix = strstr(ppc_cpu_aliases[i].model, POWERPC_CPU_TYPE_SUFFIX);
> >                ^
> > 
> > Fix this by duplicating the model string into a mutable buffer using
> > g_strdup(), storing it in the alias table, and then performing the
> > suffix truncation on the mutable copy.
> > 
> > This preserves the existing behavior while avoiding modification of
> > const data and ensures compatibility with newer compilers.
> > 
> > No functional change intended.
> > 
> > Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> > ---
> >  target/ppc/kvm.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> > index 25c28ad089c6..e71e5c0117da 100644
> > --- a/target/ppc/kvm.c
> > +++ b/target/ppc/kvm.c
> > @@ -2654,10 +2654,12 @@ static int kvm_ppc_register_host_cpu_type(void)
> >      dc = DEVICE_CLASS(ppc_cpu_get_family_class(pvr_pcc));
> >      for (i = 0; ppc_cpu_aliases[i].alias != NULL; i++) {
> >          if (g_ascii_strcasecmp(ppc_cpu_aliases[i].alias, dc->desc) == 0) {
> > +            char *model;
> >              char *suffix;
> >  
> > -            ppc_cpu_aliases[i].model = g_strdup(object_class_get_name(oc));
> > -            suffix = strstr(ppc_cpu_aliases[i].model, POWERPC_CPU_TYPE_SUFFIX);
> > +            model = g_strdup(object_class_get_name(oc));
> > +            ppc_cpu_aliases[i].model = model;
> > +            suffix = strstr(model, POWERPC_CPU_TYPE_SUFFIX);
> >              if (suffix) {
> >                  *suffix = 0;
> >              }
> > 
> 
> A const char * variable is ideally supposed to point to an immutable
> string. But even with this fix, the string that
> "ppc_cpu_aliases[i].model" points to is being changed after assignment.

Thanks, I get your point. The write in my version is to the mutable buffer
returned by g_strdup(), so it is not strictly a const write. I had originally
trimmed the duplicated buffer before assigning it to ppc_cpu_aliases[i].model,
but later reordered it to stay closer to the existing flow. Still, I agree with
the suggested cleaner ordering. I will update it in the next revision.

Thanks,
Amit

> Would the below diff (untested) be a better fix?
> 
> diff --git a/target/ppc/kvm.c b/target/ppc/kvm.c
> index 41bd03ec2a..a84e4b4636 100644
> --- a/target/ppc/kvm.c
> +++ b/target/ppc/kvm.c
> @@ -2654,13 +2654,14 @@ static int kvm_ppc_register_host_cpu_type(void)
>      dc = DEVICE_CLASS(ppc_cpu_get_family_class(pvr_pcc));
>      for (i = 0; ppc_cpu_aliases[i].alias != NULL; i++) {
>          if (strcasecmp(ppc_cpu_aliases[i].alias, dc->desc) == 0) {
> -            char *suffix;
> +            char *suffix, *model;
>  
> -            ppc_cpu_aliases[i].model = g_strdup(object_class_get_name(oc));
> -            suffix = strstr(ppc_cpu_aliases[i].model, POWERPC_CPU_TYPE_SUFFIX);
> +            model = g_strdup(object_class_get_name(oc));
> +            suffix = strstr(model, POWERPC_CPU_TYPE_SUFFIX);
>              if (suffix) {
>                  *suffix = 0;
>              }
> +            ppc_cpu_aliases[i].model = model;
>              break;
>          }
>      }

  reply	other threads:[~2026-05-08  5:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 13:43 [PATCH] target/ppc/kvm: Fix const violation when trimming CPU alias suffix Amit Machhiwal
2026-05-08  5:20 ` Gautam Menghani
2026-05-08  5:57   ` Amit Machhiwal [this message]
2026-05-11 12:17 ` Vaibhav Jain

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=20260508110407.6eeeb01e-d6-amachhiw@linux.ibm.com \
    --to=amachhiw@linux.ibm.com \
    --cc=gautam@linux.ibm.com \
    --cc=harshpb@linux.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=milesg@linux.ibm.com \
    --cc=npiggin@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    --cc=rathc@linux.ibm.com \
    --cc=vaibhav@linux.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox