From: Laurent Vivier <lvivier@redhat.com>
To: Greg Kurz <groug@kaod.org>, Thomas Huth <thuth@redhat.com>
Cc: qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options
Date: Tue, 11 Aug 2020 18:05:21 +0200 [thread overview]
Message-ID: <17a888a8-1264-f072-a044-6315a6488049@redhat.com> (raw)
In-Reply-To: <159715981316.1635409.16117540313443167075.stgit@bahia.lan>
On 11/08/2020 17:30, Greg Kurz wrote:
> Since commit 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to
> support the -prom-env parameter"), pseries machines can pre-initialize
> the "system" partition in the NVRAM with the data passed to all -prom-env
> parameters on the QEMU command line.
>
> In this cases it is assumed that all the data fits in 64 KiB, but the user
> can easily pass more and crash QEMU:
>
> $ qemu-system-ppc64 -M pseries $(for ((x=0;x<128;x++)); do \
> echo -n " -prom-env "$(for ((y=0;y<1024;y++)); do echo -n x ; done) ; \
> done) # this requires ~128 Kib
> malloc(): corrupted top size
> Aborted (core dumped)
>
> Call chrp_nvram_create_system_partition() first with its recently added
> parameter dry_run set to false, to know the required size and allocate
> the NVRAM buffer accordingly.
>
> Fixes: 61f20b9dc5b7 ("spapr_nvram: Pre-initialize the NVRAM to support the -prom-env parameter")
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
> hw/nvram/spapr_nvram.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/nvram/spapr_nvram.c b/hw/nvram/spapr_nvram.c
> index 992b818d34e7..1b74bec6200a 100644
> --- a/hw/nvram/spapr_nvram.c
> +++ b/hw/nvram/spapr_nvram.c
> @@ -165,6 +165,10 @@ static void spapr_nvram_realize(SpaprVioDevice *dev, Error **errp)
> if (ret < 0) {
> return;
> }
> + } else if (nb_prom_envs > 0) {
> + nvram->size = chrp_nvram_create_system_partition(NULL,
> + MIN_NVRAM_SIZE / 4,
> + true);
I think this will break the migration: the prom-env parameters can be on
the source side without being on the dest side. And so the pram size
will differ and the migration will fail.
Thanks,
Laurent
next prev parent reply other threads:[~2020-08-11 16:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 15:29 [PATCH 0/2] spapr/nvram: Fix QEMU crash Greg Kurz
2020-08-11 15:30 ` [PATCH 1/2] nvram: Add dry_run argument to chrp_nvram_create_system_partition() Greg Kurz
2020-08-11 15:30 ` [PATCH 2/2] spapr/nvram: Allocate enough space for all -prom-env options Greg Kurz
2020-08-11 16:05 ` Laurent Vivier [this message]
2020-08-11 16:36 ` Greg Kurz
2020-08-11 17:27 ` Laurent Vivier
2020-08-11 17:47 ` Greg Kurz
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=17a888a8-1264-f072-a044-6315a6488049@redhat.com \
--to=lvivier@redhat.com \
--cc=david@gibson.dropbear.id.au \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
--cc=qemu-ppc@nongnu.org \
--cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).