Соберем для Вас по интернет базу данных потенциальных клиентов для Вашего
Бизнеса!!! Много! Быстро! Не дорого! Узнайте об этом подробнее по
Тел\Viber\Whatsapp:+79133913837 Skype:prodawez389 Email:zradionov...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" i
Hi!
On Fri, Jan 29, 2016 at 3:54 AM, Rusty Russell wrote:
> Lucas De Marchi writes:
>> Hi!
>>
>> CC'ing Rusty and mailing lists
>
> Thanks.
>
>> Rusty and ohers: it looks like both CONFIG_CRC32 and
>> CONFIG_CRYPTO_CRC32 can be compiled as module, and they generate
>> modules with the same name,
Since the exported information can be exposed to user-space, instead of
exporting the entire request context only export the minimum information
needed.
Cc: # 3.14.x-
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 16 +++-
drivers/crypto/ccp/ccp-crypto-
On 2016-01-25 10:29:33, Herbert Xu wrote:
> On Sun, Jan 24, 2016 at 07:10:50PM +0100, Julia Lawall wrote:
> > Maybe the goto on line 1726 needs a preceding mutex_unlock?
>
> Good catch! Thanks.
>
> ---8<---
> This patch replaces uses of ablkcipher and blkcipher with skcipher,
> and the long obsol
clk_prepare()/clk_unprepare() must not be called within atomic context.
This patch calls clk_prepare() once for all from atmel_aes_probe() and
clk_unprepare() from atmel_aes_remove().
Then calls of clk_prepare_enable()/clk_disable_unprepare() were replaced
by calls of clk_enable()/clk_disable().
This patch implements the missing .import() and .export() mandatory
hooks for asynchronous hash algorithms. It also sets the relevant, non
zero, value for the .statesize field when declaring the supported SHA
algorithms. Indeed a zero value of .statesize prevents the algorithm from
being registered
On Fri, Jan 29, 2016 at 5:54 AM, Rusty Russell wrote:
> Lucas De Marchi writes:
>> Hi!
>>
>> CC'ing Rusty and mailing lists
>
> Thanks.
>
>> Rusty and ohers: it looks like both CONFIG_CRC32 and
>> CONFIG_CRYPTO_CRC32 can be compiled as module, and they generate
>> modules with the same name, crc3
Signed-off-by: Catalin Vasile
---
crypto/tcrypt.c | 190
1 file changed, 190 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index f56419d..02a3856 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -1316,6 +1316,176 @@ sta
Signed-off-by: Catalin Vasile
---
crypto/tcrypt.c | 501
1 file changed, 501 insertions(+)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 270bc4b..f56419d 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -35,6 +35,7 @@
#include
I have attached to this e-mail a set of patches that introduce bandwitdth tests
for tcrypt.
The mindset of these patches is to send as much asynchronous jobs as possible
and, after a set period of time, to count how many of them have actually been
done.
These patches are at the stage of POC (proof
__test_aead() reads MAX_IVLEN bytes from template[i].iv, but the
actual length of the initialisation vector can be shorter.
The length of the IV is already calculated earlier in the
function. Let's just reuses that.
This fix an out-of-bound error detected by KASan.
Signed-off-by: Jerome Marchand
Rusty Russell wrote:
>
> I think we could rename it to crypto_crc32, but I don't think it's the
> only one. Marco, I think depmod should probably FAIL if two modules
> have the same name, which would at least find such problems.
This patch renames it to crc32_generic.
---8<---
Subject: crypto:
On Thu, Jan 28, 2016 at 12:19:42PM +0900, Joonsoo Kim wrote:
>
> I have tested asynchronous compression APIs in zram and I saw
> regression. Atomic allocation and setting up SG lists are culprit
> for this regression. Moreover, zram optimizes linearisation
So which is it, atomic allocations or set
13 matches
Mail list logo