From: Alok Kataria <akataria@vmware.com>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
the arch/x86 maintainers <x86@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] x86-paravirt: prevent gcc from generating the wrong addressing mode
Date: Mon, 16 Mar 2009 17:59:34 -0700 [thread overview]
Message-ID: <1237251574.5906.24.camel@alok-dev1> (raw)
In-Reply-To: <49BEEDC2.2070809@goop.org>
Thanks Jeremy.
Acked-by: Alok N Kataria <akataria@vmware.com>
On Mon, 2009-03-16 at 17:24 -0700, Jeremy Fitzhardinge wrote:
> When we generate a call sequence for calling a paravirtualized
> function, we presume that the generated code is "call *0xXXXXX",
> which is a 6 byte opcode; this is larger than a normal
> direct call, and so we can patch a direct call over it.
>
> At the moment, however we give gcc enough rope to hang us by
> putting the address in a register and generating a two byte
> indirect-via-register call. Prevent this by explicitly
> dereferencing the function pointer and passing it into the
> asm as a constant.
>
> This prevents crashes in VMI, as it cannot handle unpatchable
> callsites.
>
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Cc: Alok Kataria <akataria@vmware.com>
>
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index d4fec1f..6922d16 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -395,7 +395,7 @@ extern struct pv_lock_ops pv_lock_ops;
>
> #define paravirt_type(op) \
> [paravirt_typenum] "i" (PARAVIRT_PATCH(op)), \
> - [paravirt_opptr] "m" (op)
> + [paravirt_opptr] "i" (&(op))
> #define paravirt_clobber(clobber) \
> [paravirt_clobber] "i" (clobber)
>
> @@ -449,7 +449,7 @@ int paravirt_disable_iospace(void);
> * offset into the paravirt_patch_template structure, and can therefore be
> * freely converted back into a structure offset.
> */
> -#define PARAVIRT_CALL "call *%[paravirt_opptr];"
> +#define PARAVIRT_CALL "call *%c[paravirt_opptr];"
>
> /*
> * These macros are intended to wrap calls through one of the paravirt
>
>
next prev parent reply other threads:[~2009-03-17 0:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-17 0:24 [PATCH] x86-paravirt: prevent gcc from generating the wrong addressing mode Jeremy Fitzhardinge
2009-03-17 0:59 ` Alok Kataria [this message]
2009-03-17 2:12 ` [tip:x86/urgent] x86, paravirt: " Jeremy Fitzhardinge
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=1237251574.5906.24.camel@alok-dev1 \
--to=akataria@vmware.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/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.