Am Mittwoch, 27. Januar 2016, 14:10:31 schrieb Tadeusz Struk:
Hi Tadeusz,
> Following the async change for algif_skcipher
> this patch adds similar async read to algif_aead.
>
> changes in v2:
> - change internal data structures from fixed size arrays, limited to
> RSGL_MAX_ENTRIES, to linked
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 2f313e029020f1fa5f58f38f48ff6988d67fc3c1
commit: 5821c769706561da81e9fcec4a6ca6dbbb2f30cb [54/61] sctp: Use shash
config: s390-allyesconfig (attached as .config)
reproduce:
wget
https://git.ke
On Wed, Jan 27, 2016 at 09:14:01AM -0800, Tadeusz Struk wrote:
> Before the skcipher conversion the async callback used the
> crypto_async_request directly as the ablkcipher_request.
> It wasn't quite correct, but it worked fine since the
> crypto_async_request *base was the first member of the abl
On Wed, Jan 27, 2016 at 09:13:56AM -0800, Tadeusz Struk wrote:
>
> diff --git a/crypto/skcipher.c b/crypto/skcipher.c
> index 69230e9..a9d54c0 100644
> --- a/crypto/skcipher.c
> +++ b/crypto/skcipher.c
> @@ -142,6 +142,15 @@ static int skcipher_setkey_ablkcipher(struct
> crypto_skcipher *tfm,
>
Hello, Herbert.
On Wed, Jan 27, 2016 at 04:09:26PM +0800, Herbert Xu wrote:
> On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
> > On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
> > >
> > > The acomp is also SG-based, while scomp only accepts flat buffer.
> >
> > Right, b
Dear Sir/Madam,
Clean tested working pulls CPUs and QTYs in stock.
115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690
Brand new sealed IP phones and QTYs in stock.
55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
6
On 01/27/2016 02:29 PM, kbuild test robot wrote:
> Hi Tadeusz,
>
> [auto build test ERROR on cryptodev/master]
> [also build test ERROR on v4.5-rc1 next-20160127]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
Hi Tadeusz,
[auto build test ERROR on cryptodev/master]
[also build test ERROR on v4.5-rc1 next-20160127]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits/Tadeusz-Struk/crypto-af_alg-add-async
Following the async change for algif_skcipher
this patch adds similar async read to algif_aead.
changes in v2:
- change internal data structures from fixed size arrays, limited to
RSGL_MAX_ENTRIES, to linked list model with no artificial limitation.
- use sock_kmalloc instead of kmalloc for memo
Move the helper function to common header for everybody to use.
Signed-off-by: Tadeusz Struk
---
drivers/crypto/atmel-aes.c |6 --
include/crypto/aead.h |6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/atmel-aes.c b/drivers/crypto/atmel-ae
Le 26/01/2016 14:44, Arnd Bergmann a écrit :
> gcc correctly warns that the printk output contains a variable that
> it thinks is not initialized in some cases:
>
> drivers/crypto/sunxi-ss/sun4i-ss-cipher.c: In function 'sun4i_ss_cipher_poll':
> drivers/crypto/sunxi-ss/sun4i-ss-cipher.c:254:76: wa
The private context space that was allocated for the async request was too
small. It accidentally worked fine (at least with the qat driver) because
the qat driveri, by mistake, allocated too much.
The problem started to show up since the qat driver issue has been fixed in
commit: 7768fb2ee.
We al
A user of the skcipher api may have some private context associated with
a request, like for instance the algif_skcipher does, so the api needs to
return the original skcipher_request in the callback instead of the
ablkcipher_request subtype.
Cc: # 4.4.x-
Signed-off-by: Tadeusz Struk
---
crypto
Before the skcipher conversion the async callback used the
crypto_async_request directly as the ablkcipher_request.
It wasn't quite correct, but it worked fine since the
crypto_async_request *base was the first member of the ablkcipher_request
struct. After the skcipher conversion it is not the cas
Hi Herbert,
While testing the algif_aead async patch, I have rerun the async
algif_skcipher tests and I have found some problems.
There are three different issues around algif_skcipher and skcipher.
Two are skcipher conversion related, and one is a bug in the
algif_skcipher, not related to the conv
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 2f313e029020f1fa5f58f38f48ff6988d67fc3c1
commit: 1edb82d2021c7bae96509c03c4c5ef789f1e09a3 [53/61] nfsd: Use shash
config: s390-allyesconfig (attached as .config)
reproduce:
wget
https://git.ke
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 2f313e029020f1fa5f58f38f48ff6988d67fc3c1
commit: 4a31340b36302d46207c6bb54d103d9fb568e916 [50/61] nfc: s3fwrn5: Use shash
config: s390-allyesconfig (attached as .config)
reproduce:
wget
https:
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 2f313e029020f1fa5f58f38f48ff6988d67fc3c1
commit: 9534d67195118c39edf2ec0bb74e59993c4c0677 [49/61] drbd: Use shash and
ahash
config: s390-allyesconfig (attached as .config)
reproduce:
wget
htt
On Tue, Jan 26, 2016 at 02:44:50PM +0100, Arnd Bergmann wrote:
> gcc correctly warns that the printk output contains a variable that
> it thinks is not initialized in some cases:
>
> drivers/crypto/sunxi-ss/sun4i-ss-cipher.c: In function 'sun4i_ss_cipher_poll':
> drivers/crypto/sunxi-ss/sun4i-ss-c
On Tue, Jan 26, 2016 at 02:47:10PM +0100, Arnd Bergmann wrote:
> When building the jitterentropy driver by itself, we get a link error
> when CRYPTO_RNG is not enabled as well:
>
> crypto/built-in.o: In function `jent_mod_init':
> jitterentropy-kcapi.c:(.init.text+0x98): undefined reference to
>
On Tue, Jan 26, 2016 at 05:15:03PM +0900, Joonsoo Kim wrote:
> It is unused now, so remove it.
>
> Signed-off-by: Joonsoo Kim
Applied.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list:
On Mon, Jan 25, 2016 at 04:46:09PM -0800, Megha Dey wrote:
> From: Megha Dey
>
> The _args_digest is defined as _args+_digest, both of which are the first
> members of 2 separate structures, effectively yielding _args_digest to have
> a value of zero. Thus, no errors have spawned yet due to this.
Hi!
Mimi Zohar writes:
> On Mon, 2015-11-09 at 16:18 +0100, Steffen Trumtrar wrote:
>> Hi!
>>
>> The RFC Patch attached after this cover letter is mostly for illustration
>> purposes, so please don't waste too much time reviewing the code ;-)
>>
>> For context I'll try to describe the problem
mcryptd_create_hash() fails by returning -EINVAL, causing any
driver using mcryptd to fail to load. It is because it needs
to set its statesize properly.
Signed-off-by: Rui Wang
---
crypto/mcryptd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/mcryptd.c b/crypto/mcryptd.c
index f78
hash_sendmsg/sendpage() need to wait for the completion
of crypto_ahash_init() otherwise it can cause panic.
Signed-off-by: Rui Wang
---
crypto/algif_hash.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index b4c24fe..83dc095 100
Modify __test_hash() so that hash import/export can be tested
from within the kernel by simply adding .partial = 1 to a hash
algo's struct hash_testvec where .np > 1.
v2: Leverage template[i].np as suggested by Tim Chen
Signed-off-by: Rui Wang
---
crypto/testmgr.c | 137
modprobe sha1_mb fails with the following message:
modprobe: ERROR: could not insert 'sha1_mb': No such device
It is because it needs to set its statesize and implement its
import() and export() interface.
Signed-off-by: Rui Wang
---
arch/x86/crypto/sha-mb/sha1_mb.c | 39 ++
Hi All,
This patchset resulted from the failure when loading sha1_mb. It
is because ahash drivers are now required to implement import()
and export(). Also, now it seems beneficial to add a test case in
testmgr to test import()/export(), thus:
patch01 - patch03 fix the problems while loading sha1
On 1/27/2016 4:09 PM, Herbert Xu wrote:
On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
The acomp is also SG-based, while scomp only accepts flat buffer.
Right, but do we need a pointer-based scomp at all? IPComp would
On Wed, Jan 27, 2016 at 04:03:55PM +0800, Herbert Xu wrote:
> On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
> >
> > The acomp is also SG-based, while scomp only accepts flat buffer.
>
> Right, but do we need a pointer-based scomp at all? IPComp would
> certainly be better off with a
On Wed, Jan 27, 2016 at 03:59:05PM +0800, Li, Weigang wrote:
>
> The acomp is also SG-based, while scomp only accepts flat buffer.
Right, but do we need a pointer-based scomp at all? IPComp would
certainly be better off with an SG-based interface. Any other
users of compression are presumably dea
Am Mittwoch, 27. Januar 2016, 15:35:41 schrieb Herbert Xu:
Hi Herbert,
>On Wed, Jan 27, 2016 at 08:33:00AM +0100, Stephan Mueller wrote:
>> With the current development of EXT4 encryption we currently have the
>> logic that the files are either open (read/writable) or closed (not
>> accessible).
32 matches
Mail list logo