On Wed, Feb 25, 2009 at 04:35:40PM +0100, Karl Hiramoto wrote:
The attached patch fixes my issue, but am not sure if it is correct or
will cause problems else where.
diff -Naurp linux-2.6.28.7.a/arch/arm/include/asm/scatterlist.h
linux-2.6.28.7.b/arch/arm/include/asm/scatterlist.h
---
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
We can't merge this until _all_ of ARM has been fixed for walking
scatterlist chains.
Right, this is definitely not the way to fix this bug. Because
even if ARM completely supported chaining, you still have to fix
all the other
Hi Herbert,
your patch solves the hanging modprobe (tested on top of cryptodev-2.6).
Both modules (aes_generic and aes_s390) are loaded after the modprobe
aes_s390.
Thanks a lot, Jan
On Thu, 2009-02-26 at 14:06 +0800, Herbert Xu wrote:
On Wed, Feb 25, 2009 at 05:33:50PM +, Jan Glauber
Herbert Xu wrote:
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
We can't merge this until _all_ of ARM has been fixed for walking
scatterlist chains.
Right, this is definitely not the way to fix this bug. Because
even if ARM completely supported chaining, you still have to
On Thu, Feb 26, 2009 at 08:10:43PM +0800, Herbert Xu wrote:
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
We can't merge this until _all_ of ARM has been fixed for walking
scatterlist chains.
Right, this is definitely not the way to fix this bug. Because
even if ARM completely
Russell King - ARM Linux li...@arm.linux.org.uk wrote:
I don't think you can use chained scatterlists unless the architecture
supports it. It's not a case that you have to flatten the chaining
before passing it over to the arch - it seems you're not allowed to
create a chained scatterlist in
Hi Linus:
This push fixes a 2.6.27 regression where the new test mechanism
can cause the optimised AES implementation on s390 to hang on
initial module load. The same thing can affect the VIA PadLock,
although modprobe alias ordering may have prevented it from
occurring.
Please pull from
Hi, Herbert,
I had ever heard from you that the only thing guaranteed in the
completion function of async ablkcipher cryption is the req-data has
the value you set before. The request pointer itself may be changed. But
in dm-crypt, I found they rely on request pointer in completion
function:
