From: Marcelo Tosatti <mtosatti@redhat.com>
To: Stefan Weil <sw@weilnetz.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PULL 2/3] qemu: mempath: prefault pages manually (v4)
Date: Mon, 9 Dec 2013 19:37:24 -0200 [thread overview]
Message-ID: <20131209213724.GA4453@amt.cnet> (raw)
In-Reply-To: <52A6146B.6070008@weilnetz.de>
On Mon, Dec 09, 2013 at 08:05:15PM +0100, Stefan Weil wrote:
> Hi,
>
> this patch was recently committed to git master.
>
> It now causes problems with gcc-4.7 -Werror=clobbered. See more comments
> below.
>
> Am 06.12.2013 16:54, schrieb Paolo Bonzini:
> > From: Marcelo Tosatti <mtosatti@redhat.com>
> >
> > v4: s/fail/failed/ (Peter Maydell)
> >
> > Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> > ---
> > exec.c | 59 +++++++++++++++++++++++++++++++++++++++++++-----------
> > qemu-options.hx | 2 -
> > vl.c | 4 ---
> > 3 files changed, 47 insertions(+), 18 deletions(-)
> >
> > diff --git a/exec.c b/exec.c
> > index 95c4356..f4b9ef2 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -904,6 +904,13 @@ static long gethugepagesize(const char *path)
> > return fs.f_bsize;
> > }
> >
> > +static sigjmp_buf sigjump;
> > +
> > +static void sigbus_handler(int signal)
> > +{
> > + siglongjmp(sigjump, 1);
> > +}
> > +
> > static void *file_ram_alloc(RAMBlock *block,
> > ram_addr_t memory,
> > const char *path)
> > @@ -913,9 +920,6 @@ static void *file_ram_alloc(RAMBlock *block,
> > char *c;
> > void *area;
> > int fd;
> > -#ifdef MAP_POPULATE
> > - int flags;
> > -#endif
> > unsigned long hpagesize;
> >
> > hpagesize = gethugepagesize(path);
> > @@ -963,21 +967,52 @@ static void *file_ram_alloc(RAMBlock *block,
> > if (ftruncate(fd, memory))
> > perror("ftruncate");
> >
> > -#ifdef MAP_POPULATE
> > - /* NB: MAP_POPULATE won't exhaustively alloc all phys pages in the case
> > - * MAP_PRIVATE is requested. For mem_prealloc we mmap as MAP_SHARED
> > - * to sidestep this quirk.
> > - */
> > - flags = mem_prealloc ? MAP_POPULATE | MAP_SHARED : MAP_PRIVATE;
> > - area = mmap(0, memory, PROT_READ | PROT_WRITE, flags, fd, 0);
> > -#else
> > area = mmap(0, memory, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
> > -#endif
> > if (area == MAP_FAILED) {
> > perror("file_ram_alloc: can't mmap RAM pages");
> > close(fd);
> > return (NULL);
> > }
> > +
> > + if (mem_prealloc) {
> > + int ret, i;
> > + struct sigaction act, oldact;
> > + sigset_t set, oldset;
> > +
> > + memset(&act, 0, sizeof(act));
> > + act.sa_handler = &sigbus_handler;
> > + act.sa_flags = 0;
> > +
> > + ret = sigaction(SIGBUS, &act, &oldact);
> > + if (ret) {
> > + perror("file_ram_alloc: failed to install signal handler");
> > + exit(1);
> > + }
> > +
> > + /* unblock SIGBUS */
> > + sigemptyset(&set);
> > + sigaddset(&set, SIGBUS);
> > + pthread_sigmask(SIG_UNBLOCK, &set, &oldset);
> > +
>
>
> The sigsetjmp instruction causes the compiler to assume that 'area'
> might be clobbered (sigsetjmp is declared to return twice, and gcc does
> not now anything about its semantics).
>
> > + if (sigsetjmp(sigjump, 1)) {
> > + fprintf(stderr, "file_ram_alloc: failed to preallocate pages\n");
> > + exit(1);
> > + }
> > +
> > + /* MAP_POPULATE silently ignores failures */
>
> Yes, but why this comment in this context? Here we don't use
> MAP_POPULATE and can get SIGBUS (which is not silent). Or am I wrong?
It explains why MAP_POPULATE cannot be used.
> > + for (i = 0; i < (memory/hpagesize)-1; i++) {
> > + memset(area + (hpagesize*i), 0, 1);
> > + }
> > +
> > + ret = sigaction(SIGBUS, &oldact, NULL);
> > + if (ret) {
> > + perror("file_ram_alloc: failed to reinstall signal handler");
> > + exit(1);
> > + }
> > +
> > + pthread_sigmask(SIG_SETMASK, &oldset, NULL);
> > + }
> > +
> > block->fd = fd;
> > return area;
> > }
>
>
> This is the warning shown by newer gcc versions:
>
> qemu/exec.c:921:11: error:
> variable ‘area’ might be clobbered by ‘longjmp’ or ‘vfork’
> [-Werror=clobbered]
>
> I want to get support for -Wextra, and -Wclobbered is part of -Wextra.
>
> Of course we could disable -Wclobbered and still use the other
> advantages of -Wextra,
> but this might hide real problems with clobbered variables in the future.
>
> Declaring the local variable 'area' to be volatile also fixes the warning.
>
> Any opinion how this problem should be solved?
>
> Thanks,
> Stefan
The warning is spurious, obviously. Don't see a problem with 'volatile' for area pointer.
next prev parent reply other threads:[~2013-12-09 21:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-06 15:54 [Qemu-devel] [PULL 0/3] KVM patches for 2013-12-06 Paolo Bonzini
2013-12-06 15:54 ` [Qemu-devel] [PULL 2/3] qemu: mempath: prefault pages manually (v4) Paolo Bonzini
2013-12-09 19:05 ` Stefan Weil
2013-12-09 21:37 ` Marcelo Tosatti [this message]
2013-12-06 15:54 ` [Qemu-devel] [PULL 3/3] target-i386: fix cpuid leaf 0x0d Paolo Bonzini
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=20131209213724.GA4453@amt.cnet \
--to=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
/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).