From: David Gibson <david@gibson.dropbear.id.au>
To: Dan Good <dan@gooddan.com>
Cc: ccan@lists.ozlabs.org
Subject: Re: [PATCH 3/4] altstack: Declare memory clobbers
Date: Thu, 18 Feb 2016 16:49:30 +1100 [thread overview]
Message-ID: <20160218054930.GJ15224@voom.fritz.box> (raw)
In-Reply-To: <CACNkOJMsLzcKVuhWwNYKw-LQJhjJT4kYCFLfbYUsYW911WVu1w@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4754 bytes --]
On Thu, Feb 18, 2016 at 04:45:36AM +0000, Dan Good wrote:
> Would you, please? Thank you.
Done.
>
> On Wed, Feb 17, 2016 at 10:11 PM David Gibson <david@gibson.dropbear.id.au>
> wrote:
>
> > On Wed, Feb 17, 2016 at 07:06:09AM +0000, Dan Good wrote:
> > > Looking at the objdump before and after, the clobber changes seem to add
> > a
> > > single mov instruction (9 additional bytes plus subsequent address
> > > offsets). That seems a very low price to pay for the additional
> > > assurances. -Dan
> >
> > I would tend to agree.
> >
> > Do you want to apply these patches, or will I?
> >
> > >
> > > On Tue, Feb 16, 2016 at 7:08 PM David Gibson <
> > david@gibson.dropbear.id.au>
> > > wrote:
> > >
> > > > On Tue, Feb 16, 2016 at 05:29:39PM +0000, Dan Good wrote:
> > > > > Thank you for the fixes and improvements. The clobber change is the
> > only
> > > > > that gives me pause. I think the volatile keyword on both is
> > sufficient
> > > > to
> > > > > prevent re-ordering. Are you sure we need the memory clobber?
> > > > > Thanks.
> > > >
> > > > I'm not 100% sure, but I'm fairly confident. AFAICT the volatile
> > > > keyword stops the asm section being elided if the output arguments
> > > > aren't used, and it prevents it being moved outside a loop if the
> > > > compiler things the input arguments don't change. It doesn't appear
> > > > to prevent other code, including memory accesses from being moved
> > > > around the asm. In fact, from the gcc manual:
> > > >
> > > > | Note that the compiler can move even volatile 'asm' instructions
> > > > | relative to other code, including across jump instructions. For
> > > > | example, on many targets there is a system register that controls the
> > > > | rounding mode of floating-point operations. Setting it with a
> > volatile
> > > > | 'asm', as in the following PowerPC example, does not work reliably.
> > > > |
> > > > | asm volatile("mtfsf 255, %0" : : "f" (fpenv));
> > > > | sum = x + y;
> > > > |
> > > > | The compiler may move the addition back before the volatile 'asm'.
> > To
> > > > | make it work as expected, add an artificial dependency to the 'asm'
> > by
> > > > | referencing a variable in the subsequent code, for example:
> > > > |
> > > > | asm volatile ("mtfsf 255,%1" : "=X" (sum) : "f" (fpenv));
> > > > | sum = x + y;
> > > >
> > > > > -Dan
> > > > >
> > > > > On Tue, Feb 16, 2016 at 5:04 AM David Gibson <
> > > > david@gibson.dropbear.id.au>
> > > > > wrote:
> > > > >
> > > > > > altstack includes a couple of inline asm blocks with x86 push and
> > pop
> > > > > > instructions. These instructions will access memory (the stack),
> > but
> > > > > > that's not declared in inline asm statement. We seem to be getting
> > > > away
> > > > > > with it, but in theory that could allow the compiler to re-order
> > > > accesses
> > > > > > to local variables across the asm block. Since those blocks
> > change the
> > > > > > location of the stack, that could be very bad.
> > > > > >
> > > > > > Adding a "memory" clobber should prevent this (effectively making
> > the
> > > > asm
> > > > > > blocks a compiler memory barrier).
> > > > > >
> > > > > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > > > > > ---
> > > > > > ccan/altstack/altstack.c | 5 +++--
> > > > > > 1 file changed, 3 insertions(+), 2 deletions(-)
> > > > > >
> > > > > > diff --git a/ccan/altstack/altstack.c b/ccan/altstack/altstack.c
> > > > > > index 640344d..6351293 100644
> > > > > > --- a/ccan/altstack/altstack.c
> > > > > > +++ b/ccan/altstack/altstack.c
> > > > > > @@ -108,9 +108,10 @@ int altstack(rlim_t max, void *(*fn)(void *),
> > void
> > > > > > *arg, void **out)
> > > > > > "mov %1, %%rsp\n\t"
> > > > > > "sub $8, %%rsp\n\t"
> > > > > > "push %%r10"
> > > > > > - : "=r" (rsp_save_[0]) : "0" (m + max) :
> > "r10");
> > > > > > + : "=r" (rsp_save_[0]) : "0" (m + max) :
> > "r10",
> > > > > > "memory");
> > > > > > out_ = fn_(arg_);
> > > > > > - asm volatile ("pop %rsp");
> > > > > > + asm volatile ("pop %%rsp"
> > > > > > + : : : "memory");
> > > > > > ret = 0;
> > > > > > if (out) *out = out_;
> > > > > > }
> > > > > >
> > > > > >
> > > >
> > > >
> >
> >
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
ccan mailing list
ccan@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/ccan
next prev parent reply other threads:[~2016-02-18 5:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-16 6:09 [PATCH 0/4] altstack: Small bugfixes David Gibson
2016-02-16 6:09 ` [PATCH 1/4] altstack: Increase signal stack size David Gibson
2016-02-16 6:09 ` [PATCH 2/4] altstack: Include config.h in run.c David Gibson
2016-02-16 6:09 ` [PATCH 3/4] altstack: Declare memory clobbers David Gibson
2016-02-16 17:29 ` Dan Good
2016-02-17 0:09 ` David Gibson
[not found] ` <CACNkOJPwRNWyUw+mv=RR+9hShPfUaCu3EGbNTeOhGRmmc6zA-w@mail.gmail.com>
2016-02-18 3:09 ` David Gibson
[not found] ` <CACNkOJMsLzcKVuhWwNYKw-LQJhjJT4kYCFLfbYUsYW911WVu1w@mail.gmail.com>
2016-02-18 5:49 ` David Gibson [this message]
2016-02-16 6:09 ` [PATCH 4/4] altstack: Clarify checking macros David Gibson
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=20160218054930.GJ15224@voom.fritz.box \
--to=david@gibson.dropbear.id.au \
--cc=ccan@lists.ozlabs.org \
--cc=dan@gooddan.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