On Mon, Mar 24, 2014 at 01:01:04AM +0530, Monam Agarwal wrote:
This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
The rcu_assign_pointer() ensures that the initialization of a structure
is carried out before storing a pointer to that structure.
And in the
On 24/03/14 12:16, Neil Horman wrote:
On Mon, Mar 24, 2014 at 01:01:04AM +0530, Monam Agarwal wrote:
This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
The rcu_assign_pointer() ensures that the initialization of a structure
is carried out before storing a pointer to
On 3/22/2014 6:24 PM, Ben Hutchings wrote:
On Fri, 2014-03-21 at 00:35 +0545, Yashpal Dutta wrote:
Job ring is suspended gracefully and resume afresh.
Both Sleep (where device will remain powered-on) and Deep-sleep (where
device will be powered-down are handled gracefully. Persistance sessions
Commit 7c1da8d0d0 crypto: sha - SHA1 transform x86_64 AVX2
accidentally disabled the AVX variant by making the avx_usable() test
not only fail in case the CPU doesn't support AVX or OSXSAVE but also
if it doesn't support AVX2.
Fix that regression by splitting up the AVX/AVX2 test into two
The AVX2 implementation might waste up to a page of stack memory because
of a wrong alignment calculation. This will, in the worst case, increase
the stack usage of sha1_transform_avx2() alone to 5.4 kB -- way to big
for a kernel function. Even worse, it might also allocate *less* bytes
than
There is really no need to page align sha1_transform_avx2. The default
alignment is just fine. This is not the hot code but only the entry
point, after all.
Cc: Chandramouli Narayanan mo...@linux.intel.com
Cc: H. Peter Anvin h...@zytor.com
Cc: Marek Vasut ma...@denx.de
Signed-off-by: Mathias
The recent addition of the AVX2 variant of the SHA1 hash function wrongly
disabled the AVX variant by introducing a flaw in the feature test. Fixed
in patch 1.
The alignment calculations of the AVX2 assembler implementation are
questionable, too. Especially the page alignment of the stack pointer
On 03/24/2014 09:10 AM, Mathias Krause wrote:
The recent addition of the AVX2 variant of the SHA1 hash function wrongly
disabled the AVX variant by introducing a flaw in the feature test. Fixed
in patch 1.
The alignment calculations of the AVX2 assembler implementation are
questionable,
On Mon, 2014-03-24 at 17:10 +0100, Mathias Krause wrote:
The recent addition of the AVX2 variant of the SHA1 hash function wrongly
disabled the AVX variant by introducing a flaw in the feature test. Fixed
in patch 1.
The alignment calculations of the AVX2 assembler implementation are
On 03/24/2014 09:10 AM, Mathias Krause wrote:
The recent addition of the AVX2 variant of the SHA1 hash function wrongly
disabled the AVX variant by introducing a flaw in the feature test. Fixed
in patch 1.
The alignment calculations of the AVX2 assembler implementation are
questionable,
On Monday, March 24, 2014 at 05:10:36 PM, Mathias Krause wrote:
The recent addition of the AVX2 variant of the SHA1 hash function wrongly
disabled the AVX variant by introducing a flaw in the feature test. Fixed
in patch 1.
The alignment calculations of the AVX2 assembler implementation are
On Thursday, March 20, 2014 at 03:48:06 PM, Ard Biesheuvel wrote:
This patch adds support for the SHA-224 and SHA-256 hash algorithms using
the NEON based SHA-256 instructions that were introduced in ARM v8.
Signed-off-by: Ard Biesheuvel ard.biesheu...@linaro.org
---
[...]
+ * Copyright
12 matches
Mail list logo
