From: Cesar Eduardo Barros <cesarb@cesarb.eti.br>
To: Daniel Borkmann <dborkman@redhat.com>, James Yonan <james@openvpn.net>
Cc: linux-crypto@vger.kernel.org,
Herbert Xu <herbert@gondor.hengli.com.au>,
"David S. Miller" <davem@davemloft.net>,
Florian Weimer <fw@deneb.enyo.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] crypto: more robust crypto_memneq
Date: Mon, 25 Nov 2013 20:00:46 -0200 [thread overview]
Message-ID: <5293C88E.9000203@cesarb.eti.br> (raw)
In-Reply-To: <52937A51.6070603@redhat.com>
Em 25-11-2013 14:26, Daniel Borkmann escreveu:
> On 11/25/2013 04:59 PM, James Yonan wrote:
>> This approach using __asm__ ("" : "=r" (var) : "0" (var)) to try to
>> prevent compiler optimizations of var is interesting.
>>
>> I like the fact that it's finer-grained than -Os and doesn't preclude
>> inlining.
>
> Agreed. This looks much better than the Makefile workaround. Do we have
> a hard guarantee that in future, this will not be detected and optimized
> away by the compiler?
That guarantee is something only the compiler people can give you. But
given that RELOC_HIDE will break if that ever changes, and there are
other constructs depending on the optimization-blocking behavior of
inline assembly (like the many kinds of barriers in the kernel), I am
not worried about that.
--
Cesar Eduardo Barros
cesarb@cesarb.eti.br
next prev parent reply other threads:[~2013-11-25 22:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-24 21:12 [PATCH] crypto: more robust crypto_memneq Cesar Eduardo Barros
2013-11-24 21:12 ` Cesar Eduardo Barros
2013-11-25 15:59 ` James Yonan
2013-11-25 15:59 ` James Yonan
2013-11-25 16:26 ` Daniel Borkmann
2013-11-25 22:00 ` Cesar Eduardo Barros [this message]
2013-11-25 21:56 ` Cesar Eduardo Barros
2013-11-25 21:56 ` Cesar Eduardo Barros
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=5293C88E.9000203@cesarb.eti.br \
--to=cesarb@cesarb.eti.br \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=fw@deneb.enyo.de \
--cc=herbert@gondor.hengli.com.au \
--cc=james@openvpn.net \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.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.