Hi, On Thu, Dec 02, 2010 at 02:14:41PM +0800, Herbert Xu wrote: > > Yes, it does, but triggering the bug is not really trivial. I've had > > best results with a speed testing tool using the asynchronous interface, > > memory corruption occured in each run. The same tool operating > > synchronously doesn't crash as soon, but having three or more instances > > running in parallel yields the same result. > > > > This problem is so racey, a simple printk statement at the beginning of > > padlock_xcrypt_ecb() fixes it. Enclosing the same function's content in > > lock_kernel()/unlock_kernel() statements helps as well. > > Interesting. Do you have preemption enabled? Yes, CONFIG_PREEMPT is active in my test system's kernel. > Can you share the test program with us? You can get it along with the actual cryptodev-implementation at http://repo.or.cz/w/cryptodev-linux.git. I've been testing with speed.c and async_speed.c, both can be found inside the examples directory. Greetings, Phil -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
