Re: [PATCH v3] poly1305: generic C can be faster on chips with slow unaligned access

[Jason A. Donenfeld]

Hello friendly test robot,

On Sun, Nov 13, 2016 at 12:27 AM, kbuild test robot  wrote:
> Hi Jason,
>
> [auto build test ERROR on cryptodev/master]

That error was fixed by v4 in this series. The version that should be
tested and ultimately applied is v4 and can be found here:

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1265977.html

Regards from a human,
Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] poly1305: generic C can be faster on chips with slow unaligned access

[kbuild test robot]

Hi Jason,

[auto build test ERROR on cryptodev/master]
[also build test ERROR on v4.9-rc4 next-2016]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/poly1305-generic-C-can-be-faster-on-chips-with-slow-unaligned-access/20161108-053912
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   crypto/poly1305_generic.c: In function 'poly1305_setrkey':
>> crypto/poly1305_generic.c:63:2: error: implicit declaration of function 
>> 'get_unaligned_le32'

vim +/get_unaligned_le32 +63 crypto/poly1305_generic.c

57  }
58  EXPORT_SYMBOL_GPL(crypto_poly1305_setkey);
59  
60  static void poly1305_setrkey(struct poly1305_desc_ctx *dctx, const u8 
*key)
61  {
62  /* r &= 0xffc0ffc0ffc0fff */
  > 63  dctx->r[0] = (get_unaligned_le32(key +  0) >> 0) & 0x3ff;
64  dctx->r[1] = (get_unaligned_le32(key +  3) >> 2) & 0x303;
65  dctx->r[2] = (get_unaligned_le32(key +  6) >> 4) & 0x3ffc0ff;
66  dctx->r[3] = (get_unaligned_le32(key +  9) >> 6) & 0x3f03fff;

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v3] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512

[Will Deacon]

Hi Ard,

On Sat, Nov 12, 2016 at 01:32:33PM +0100, Ard Biesheuvel wrote:
> This integrates both the accelerated scalar and the NEON implementations
> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
> 
> Relative performance compared to the respective generic C versions:
> 
>  |  SHA256-scalar  | SHA256-NEON* |  SHA512  |
>  +-+--+--+
>  Cortex-A53  |  1.63x  | 1.63x|   2.34x  |
>  Cortex-A57  |  1.43x  | 1.59x|   1.95x  |
>  Cortex-A73  |  1.26x  | 1.56x| ?|
> 
> The core crypto code was authored by Andy Polyakov of the OpenSSL
> project, in collaboration with whom the upstream code was adapted so
> that this module can be built from the same version of sha512-armv8.pl.
> 
> The version in this patch was taken from OpenSSL commit
> 
>866e505e0d66 sha/asm/sha512-armv8.pl: add NEON version of SHA256.
> 
> * The core SHA algorithm is fundamentally sequential, but there is a
>   secondary transformation involved, called the schedule update, which
>   can be performed independently. The NEON version of SHA-224/SHA-256
>   only implements this part of the algorithm using NEON instructions,
>   the sequential part is always done using scalar instructions.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> v3: at Will's request, the generated assembly files are now included
> as .S_shipped files, for which generic build rules are defined
> already. Note that this has caused issues in the past with
> patchwork, so for Herbert's convenience, the patch can be pulled
> from http://git.kernel.org/cgit/linux/kernel/git/ardb/linux.git,
> branch arm64-sha256 (based on today's cryptodev)

Thanks.

Looking at the generated code, I see references to __ARMEB__ and __ILP32__.
The former is probably a bug, whilst the second is not required. There are
also some commented out instructions, which is weird.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/11] getting back -Wmaybe-uninitialized

[Jonathan Cameron]

On 11/11/16 19:49, Arnd Bergmann wrote:
> On Friday, November 11, 2016 9:13:00 AM CET Linus Torvalds wrote:
>> On Thu, Nov 10, 2016 at 8:44 AM, Arnd Bergmann  wrote:
>>>
>>> Please merge these directly if you are happy with the result.
>>
>> I will take this.
> 
> Thanks a lot!
>  
>> I do see two warnings, but they both seem to be valid and recent,
>> though, so I have no issues with the spurious cases.
> 
> Ok, both of them should have my fixes coming your way already.
> 
>> Warning #1:
>>
>>   sound/soc/qcom/lpass-platform.c: In function ‘lpass_platform_pcmops_open’:
>>   sound/soc/qcom/lpass-platform.c:83:29: warning: ‘dma_ch’ may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
>> drvdata->substream[dma_ch] = substream;
>> ~~~^~~
>>
>> and 'dma_ch' usage there really is crazy and wrong. Broken by
>> 022d00ee0b55 ("ASoC: lpass-platform: Fix broken pcm data usage")
> 
> Right, the patches crossed here, the bugfix patch that introduced
> this came into linux-next over the kernel summit, and the fix I
> sent on Tuesday made it into Mark Brown's tree on Wednesday but not
> before you pulled alsa tree. It should be fixed the next time you
> pull from the alsa tree, the commit is
> 
> 3b89e4b77ef9 ("ASoC: lpass-platform: initialize dma channel number")
>  
>> Warning #2 is not a real bug, but it's reasonable that gcc doesn't
>> know that storage_bytes (chip->read_size) has to be 2/4. Again,
>> introduced recently by commit 231147ee77f3 ("iio: maxim_thermocouple:
>> Align 16 bit big endian value of raw reads"), so you didn't see it.
> 
> This is the one I mentioned in the commit message as one that
> is fixed in linux-next and that should make it in soon.
> 
>>   drivers/iio/temperature/maxim_thermocouple.c: In function
>> ‘maxim_thermocouple_read_raw’:
>>   drivers/iio/temperature/maxim_thermocouple.c:141:5: warning: ‘ret’
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>> if (ret)
>>^
>>   drivers/iio/temperature/maxim_thermocouple.c:128:6: note: ‘ret’ was
>> declared here
>> int ret;
>> ^~~
>>
>> and I guess that code can just initialize 'ret' to '-EINVAL' or
>> something to just make the theoretical "somehow we had a wrong
>> chip->read_size" case error out cleanly.
> 
> Right, that was my conclusion too. I sent the bugfix on Oct 25
> for linux-next but it didn't make it in until this Monday, after
> you pulled the patch that introduced it on Oct 29.
> 
> The commit in staging-testing is
> 32cb7d27e65d ("iio: maxim_thermocouple: detect invalid storage size in 
> read()")
> 
> Greg and Jonathan, I see now that this is part of the 'iio-for-4.10b'
> branch, so I suspect you were not planning to send this before the
> merge window. Could you make sure this ends up in v4.9 so we get
> a clean build when -Wmaybe-uninitialized gets enabled again?
I'll queue this up and send a pull to Greg tomorrow.

Was highly doubtful that a false warning suppression (be it an
understandable one) was worth sending mid cycle, hence it was
taking the slow route.

Jonathan
> 
>   Arnd
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512

[Ard Biesheuvel]

On 11 November 2016 at 20:56, Will Deacon  wrote:
> On Fri, Nov 11, 2016 at 09:51:13PM +0800, Ard Biesheuvel wrote:
>> This integrates both the accelerated scalar and the NEON implementations
>> of SHA-224/256 as well as SHA-384/512 from the OpenSSL project.
>>
>> Relative performance compared to the respective generic C versions:
>>
>>  |  SHA256-scalar  | SHA256-NEON* |  SHA512  |
>>  +-+--+--+
>>  Cortex-A53  |  1.63x  | 1.63x|   2.34x  |
>>  Cortex-A57  |  1.43x  | 1.59x|   1.95x  |
>>  Cortex-A73  |  1.26x  | 1.56x| ?|
>>
>> The core crypto code was authored by Andy Polyakov of the OpenSSL
>> project, in collaboration with whom the upstream code was adapted so
>> that this module can be built from the same version of sha512-armv8.pl.
>>
>> The version in this patch was taken from OpenSSL commit
>>
>>866e505e0d66 sha/asm/sha512-armv8.pl: add NEON version of SHA256.
>>
>> * The core SHA algorithm is fundamentally sequential, but there is a
>>   secondary transformation involved, called the schedule update, which
>>   can be performed independently. The NEON version of SHA-224/SHA-256
>>   only implements this part of the algorithm using NEON instructions,
>>   the sequential part is always done using scalar instructions.
>>
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>
>> This supersedes the SHA-256-NEON-only patch I sent out about 6 weeks ago.
>>
>> Will, Catalin: note that this pulls in a .pl script, and adds a build rule
>> locally in arch/arm64/crypto to generate .S files on the fly from Perl
>> scripts. I will leave it to you to decide whether you are ok with this as
>> is, or whether you prefer .S_shipped files, in which case the Perl script
>> is only included as a reference (this is how we did it for arch/arm in the
>> past, but given that it adds about 3000 lines of generated code to the patch,
>> I think we may want to simply keep it as below)
>
> I think we should include the shipped files too. 3000 lines isn't that much
> in the grand scheme of things, and there will be people who complain about
> the unconditional perl dependency.
>

OK, fair enough. I will repost with the generated files included.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html