Re: crypto_remove_spawns: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
On Mon, Feb 15, 2010 at 09:47:25AM +0200, Alexey Dobriyan wrote:
On Mon, Feb 15, 2010 at 7:27 AM, Herbert Xu herb...@gondor.apana.org.au
wrote:
Is this reproducible every time you unload aes_x86_64 after boot?
No, what I do is
1. setup ipcomp in tunnel mode _in fresh netns_ and immediately exit
2. modprobe/rmmod all modules (not much)
~1 hour of this workload and it hits sometimes with aes_x86_64,
sometimes with aes_generic.
Was this with that IPCOMP bug fixed?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: crypto_remove_spawns: BUG: unable to handle kernel NULL pointer dereference at 0000000000000018
On Mon, Feb 15, 2010 at 10:11 AM, Herbert Xu herb...@gondor.apana.org.au wrote: On Mon, Feb 15, 2010 at 09:47:25AM +0200, Alexey Dobriyan wrote: On Mon, Feb 15, 2010 at 7:27 AM, Herbert Xu herb...@gondor.apana.org.au wrote: Is this reproducible every time you unload aes_x86_64 after boot? No, what I do is 1. setup ipcomp in tunnel mode _in fresh netns_ and immediately exit 2. modprobe/rmmod all modules (not much) ~1 hour of this workload and it hits sometimes with aes_x86_64, sometimes with aes_generic. Was this with that IPCOMP bug fixed? Yes, ipcomp bug triggers almost immediately. Anyway, this is just description of what I do. -- 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/arc4: convert this stream cipher into a block cipher
* Herbert Xu | 2010-02-15 08:10:08 [+0800]: How about we just remove it? It's not on a hot path anyway. Sure. I can do this when integrating the patch so you don't have to resend. Okay, thanks. Thanks, Sebastian -- 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: Possible bug: blkcipher_walk_done()
Hi, Strange what you say if err 0 the page are never mapped... Pages mapped before... and they are not unmapped and mapped again... So they left mapped.. And yes... if HW fails then it need to break the function and unmap previously mapped pages. I will submit patches for review soon to this list. Thanks for your discussion! - Dmitry ext Herbert Xu wrote: On Wed, Feb 10, 2010 at 09:42:13AM +, Dmitry Kasatkin wrote: Hi, It seems that there is a mistake in the implementation of int blkcipher_walk_done(struct blkcipher_desc *desc, struct blkcipher_walk *walk, int err) blkcipher_walk_virt() will call crypto_kmap() to map page. But in the case then err argument is 0 and we cannot continue then blkcipher_walk_done() will not unmap the page. What do you think? Only blkcipher.c itself calls blkcipher_walk_done with err 0. Algorithms are not supposed to do that as this interface is only for synchronous implementations. When blkcipher.c uses it with err 0 the pages are never mapped. Do you need to be able to fail with a synchronous algorithm? Cheers, -- 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: crypto_shash_update CRYPTO_TFM_REQ_MAY_SLEEP
Hi,
Alg code and drivers uses req/desc-flags to use GFP_KERNEL or GFP_ATOMIC.
crypto_kmap() - Does not it make a sense to also use kmap/kmap_atomic
instead of just kmap_atomic()?
---
static inline void *crypto_kmap(struct page *page, int out)
{
return kmap_atomic(page, crypto_kmap_type(out));
}
-
It is now not only about sync but also async code.
Would be nice to wait for hash completion in some cases...
What do you think?
What is the reason to have only kmap_atomic()?
- Dmitry
Kasatkin Dmitry (Nokia-D/Helsinki) wrote:
Hi,
Anyway, crypto driver is called with CRYPTO_TFM_REQ_MAY_SLEEP flag set.
It basically mean it can sleep.
But it is not because of kmap_atomic()
So no possibility to know if to use GFP_KERNEL or GFP_ATOMIC.
I guess that is not correct way.
If driver cannot sleep then CRYPTO_TFM_REQ_MAY_SLEEP should not be set
when calling it.
Even sync implementation might use HW and sleep a bit while HW is doing
calculation...
- Dmitry
ext Herbert Xu wrote:
Dmitry Kasatkin dmitry.kasat...@nokia.com wrote:
One interesting issue
Many clients in the kernel set CRYPTO_TFM_REQ_MAY_SLEEP to desc.flags.
It is used by crypto_yeld().
That flag is really only meaningful for synchronous implementations.
For hardware crypto that is asynchronous, you can simply ignore it
in most cases (exceptions include invoking a syncrhonous backup, for
example).
Cheers,
--
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
--
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: crypto_shash_update CRYPTO_TFM_REQ_MAY_SLEEP
On Tue, Feb 16, 2010 at 08:36:08AM +0200, Dmitry Kasatkin wrote:
Hi,
we have HW accelerator which can be accessed without DMA.
CPU just sequentially writes data to the port and then reads result.
Well if that's the case then you definitely don't need anything
other than kmap_atomic. You should be able to map it atomically,
write the data out, unmap it, and then wait for the completion.
Non-atomic kmaps should be avoided if at all possible.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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: crypto_shash_update CRYPTO_TFM_REQ_MAY_SLEEP
On Tue, Feb 16, 2010 at 09:05:10AM +0200, Dmitry Kasatkin wrote:
Hi,
How is it possible to wait for completion here?: shash.c
shash_compat_digest()
{
data = crypto_kmap(sg_page(sg), 0);
err = crypto_shash_digest(desc, data + offset, nbytes, out);
crypto_kunmap(data, 0);
}
It happens as single operation/call.
Well you'd do it as an ahash algorithm, not shash.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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
