* [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
@ 2013-01-21 17:02 Matt Sealey
2013-01-21 22:46 ` Nicolas Pitre
0 siblings, 1 reply; 6+ messages in thread
From: Matt Sealey @ 2013-01-21 17:02 UTC (permalink / raw)
To: linux-kernel, linux-crypto
Cc: David S. Miller, Herbert Xu, Russell King, linux-arm-kernel, Matt Sealey
The optimized assembler SHA1 code for ARM does not conform to Thumb2
register usage requirements, so it cannot be built when the kernel is
configured with THUMB2_KERNEL.
Fix the FTBFS for now by preventing misconfigurations of the kernel.
Signed-off-by: Matt Sealey <matt@genesi-usa.com>
---
crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 4641d95..304d60b 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -472,7 +472,7 @@ config CRYPTO_SHA1_SPARC64
config CRYPTO_SHA1_ARM
tristate "SHA1 digest algorithm (ARM-asm)"
- depends on ARM
+ depends on ARM && !THUMB2_KERNEL
select CRYPTO_SHA1
select CRYPTO_HASH
help
--
1.7.10.4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
2013-01-21 17:02 [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL Matt Sealey
@ 2013-01-21 22:46 ` Nicolas Pitre
2013-01-22 0:54 ` Matt Sealey
0 siblings, 1 reply; 6+ messages in thread
From: Nicolas Pitre @ 2013-01-21 22:46 UTC (permalink / raw)
To: Matt Sealey
Cc: linux-kernel, linux-crypto, David S. Miller, Herbert Xu,
Russell King, linux-arm-kernel
On Mon, 21 Jan 2013, Matt Sealey wrote:
> The optimized assembler SHA1 code for ARM does not conform to Thumb2
> register usage requirements, so it cannot be built when the kernel is
> configured with THUMB2_KERNEL.
>
> Fix the FTBFS for now by preventing misconfigurations of the kernel.
>
> Signed-off-by: Matt Sealey <matt@genesi-usa.com>
A .arm directive at the top of the assembly code would be a better
"fix", as that wouldn't reduce functionality.
Yet, I'd invite you to have a look at commit 638591cd7b in linux-next.
Nicolas
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
2013-01-21 22:46 ` Nicolas Pitre
@ 2013-01-22 0:54 ` Matt Sealey
2013-01-22 7:46 ` Jussi Kivilinna
0 siblings, 1 reply; 6+ messages in thread
From: Matt Sealey @ 2013-01-22 0:54 UTC (permalink / raw)
To: Nicolas Pitre
Cc: LKML, linux-crypto, David S. Miller, Herbert Xu, Russell King,
Linux ARM Kernel ML, Dave Martin, David McCullough
On Mon, Jan 21, 2013 at 4:46 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Mon, 21 Jan 2013, Matt Sealey wrote:
>
>> The optimized assembler SHA1 code for ARM does not conform to Thumb2
>> register usage requirements, so it cannot be built when the kernel is
>> configured with THUMB2_KERNEL.
>>
>> Fix the FTBFS for now by preventing misconfigurations of the kernel.
>>
>> Signed-off-by: Matt Sealey <matt@genesi-usa.com>
>
> A .arm directive at the top of the assembly code would be a better
> "fix", as that wouldn't reduce functionality.
If I recall, doing that last time for ssi-fiq.S was the wrong solution
and it was suggesed proper configuration (on top of possibly rewriting
the assembly) was better than hacking around in the assembly..
> Yet, I'd invite you to have a look at commit 638591cd7b in linux-next.
I took a peek, and invite you to ignore my patch. I only tracked the
top of Linus' tree..
That said, it seems nobody benchmarked this on something different
than IXP425 or KS8695 to see if it's markedly faster than the
(moderately recently updated) C-code implementation outside of the
mentioned in the logs for initial commit? It seems like rather a
specific optimization for a rather specific use case for rather
specific processors (and therefore a small test base) probably meant
for a very specific product line somewhere. Whether you get any
benefit in enabling this config item or not for any other ARM platform
is up for debate, isn't it?
If it *is* in fact much faster everywhere, and it works in any ARM or
THUMB2 configuration, there's a case to be built for it being the
default ARM implementation for AES and SHA1..
This question is to the implementor/committer (Dave McCullough), how
exactly did you measure the benchmark and can we reproduce it on some
other ARM box?
If it's long and laborious and not so important to test the IPsec
tunnel use-case, what would be the simplest possible benchmark to see
if the C vs. assembly version is faster for a particular ARM device? I
can get hold of pretty much any Cortex-A8 or Cortex-A9 that matters, I
have access to a Chromebook for A15, and maybe an i.MX27 or i.MX35 and
a couple Marvell boards (ARMv6) if I set my mind to it... that much
testing implies we find a pretty concise benchmark though with a
fairly common kernel version we can spread around (i.MX, OMAP and the
Chromebook, I can handle, the rest I'm a little wary of bothering to
spend too much time on). I think that could cover a good swath of
not-ARMv5 use cases from lower speeds to quad core monsters.. but I
might stick to i.MX to start with..
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
2013-01-22 0:54 ` Matt Sealey
@ 2013-01-22 7:46 ` Jussi Kivilinna
2013-01-22 7:50 ` Jussi Kivilinna
0 siblings, 1 reply; 6+ messages in thread
From: Jussi Kivilinna @ 2013-01-22 7:46 UTC (permalink / raw)
To: Matt Sealey
Cc: Nicolas Pitre, LKML, linux-crypto, David S. Miller, Herbert Xu,
Russell King, Linux ARM Kernel ML, Dave Martin, David McCullough
Quoting Matt Sealey <matt@genesi-usa.com>:
> This question is to the implementor/committer (Dave McCullough), how
> exactly did you measure the benchmark and can we reproduce it on some
> other ARM box?
>
> If it's long and laborious and not so important to test the IPsec
> tunnel use-case, what would be the simplest possible benchmark to see
> if the C vs. assembly version is faster for a particular ARM device? I
> can get hold of pretty much any Cortex-A8 or Cortex-A9 that matters, I
> have access to a Chromebook for A15, and maybe an i.MX27 or i.MX35 and
> a couple Marvell boards (ARMv6) if I set my mind to it... that much
> testing implies we find a pretty concise benchmark though with a
> fairly common kernel version we can spread around (i.MX, OMAP and the
> Chromebook, I can handle, the rest I'm a little wary of bothering to
> spend too much time on). I think that could cover a good swath of
> not-ARMv5 use cases from lower speeds to quad core monsters.. but I
> might stick to i.MX to start with..
There is 'tcrypt' module in crypto/ for quick benchmarking. 'modprobe
tcrypt mode=500 sec=1' tests AES in various cipher-modes, using
different buffer sizes and outputs results to kernel log.
-Jussi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
2013-01-22 7:46 ` Jussi Kivilinna
@ 2013-01-22 7:50 ` Jussi Kivilinna
2013-01-22 19:43 ` Matt Sealey
0 siblings, 1 reply; 6+ messages in thread
From: Jussi Kivilinna @ 2013-01-22 7:50 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Matt Sealey, Nicolas Pitre, LKML, linux-crypto, David S. Miller,
Herbert Xu, Russell King, Linux ARM Kernel ML, Dave Martin,
David McCullough
Quoting Jussi Kivilinna <jussi.kivilinna@mbnet.fi>:
> Quoting Matt Sealey <matt@genesi-usa.com>:
>
>> This question is to the implementor/committer (Dave McCullough), how
>> exactly did you measure the benchmark and can we reproduce it on some
>> other ARM box?
>>
>> If it's long and laborious and not so important to test the IPsec
>> tunnel use-case, what would be the simplest possible benchmark to see
>> if the C vs. assembly version is faster for a particular ARM device? I
>> can get hold of pretty much any Cortex-A8 or Cortex-A9 that matters, I
>> have access to a Chromebook for A15, and maybe an i.MX27 or i.MX35 and
>> a couple Marvell boards (ARMv6) if I set my mind to it... that much
>> testing implies we find a pretty concise benchmark though with a
>> fairly common kernel version we can spread around (i.MX, OMAP and the
>> Chromebook, I can handle, the rest I'm a little wary of bothering to
>> spend too much time on). I think that could cover a good swath of
>> not-ARMv5 use cases from lower speeds to quad core monsters.. but I
>> might stick to i.MX to start with..
>
> There is 'tcrypt' module in crypto/ for quick benchmarking.
> 'modprobe tcrypt mode=500 sec=1' tests AES in various cipher-modes,
> using different buffer sizes and outputs results to kernel log.
>
Actually mode=200 might be better, as mode=500 is for asynchronous
implementations and might use hardware crypto if such device/module is
available.
-Jussi
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL
2013-01-22 7:50 ` Jussi Kivilinna
@ 2013-01-22 19:43 ` Matt Sealey
0 siblings, 0 replies; 6+ messages in thread
From: Matt Sealey @ 2013-01-22 19:43 UTC (permalink / raw)
To: Jussi Kivilinna
Cc: Nicolas Pitre, LKML, linux-crypto, David S. Miller, Herbert Xu,
Russell King, Linux ARM Kernel ML, Dave Martin, David McCullough
On Tue, Jan 22, 2013 at 1:50 AM, Jussi Kivilinna
<jussi.kivilinna@mbnet.fi> wrote:
>
>> There is 'tcrypt' module in crypto/ for quick benchmarking. 'modprobe
>> tcrypt mode=500 sec=1' tests AES in various cipher-modes, using different
>> buffer sizes and outputs results to kernel log.
>>
>
> Actually mode=200 might be better, as mode=500 is for asynchronous
> implementations and might use hardware crypto if such device/module is
> available.
Okeydokey I'll start running some tests..
--
Matt Sealey <matt@genesi-usa.com>
Product Development Analyst, Genesi USA, Inc.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-01-22 19:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-01-21 17:02 [PATCH] crypto: fix FTBFS with ARM SHA1-asm and THUMB2_KERNEL Matt Sealey
2013-01-21 22:46 ` Nicolas Pitre
2013-01-22 0:54 ` Matt Sealey
2013-01-22 7:46 ` Jussi Kivilinna
2013-01-22 7:50 ` Jussi Kivilinna
2013-01-22 19:43 ` Matt Sealey
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).