Hi Sorry I haven't answered this before. And sorry for top-posting but I can now summarize this so it makes sense.. I tested this with Intel Medfield hardware and SEP driver (drivers/staging/sep). It turned out that SEP driver crashed while encrypting extents of a page. I also did a test where I mocked "err = -EINPROGRESS;" into ecryptfs_encrypt_extent_done and tested what it would produce. No crashes/oops whatsoever. So I guess this was completely false alarm from ecryptfs perspective. /Jarkko On Sat, Apr 6, 2013, at 2:52, Tyler Hicks wrote: > On 2013-03-30 15:57:10, Jarkko Sakkinen wrote: > > Hi > > > > I've been experimenting with async branch of ecryptfs for some > > workloads. Sometimes it crashes so that ecryptfs_encrypt_extent_done() > > first reports -EINPROGRESS (-115) to kernel log. After that it crashes > > in ablkcipher_walk_phys(). > > Were you building with Zeev's patch titled "eCryptfs: ablkcipher support > - add workqueue"? A (temporary) link to the patch can be found here: > > http://git.kernel.org/cgit/linux/kernel/git/tyhicks/ecryptfs.git/commit/?h=async > > Do you have a way to reproduce this? Any exotic hardware? Any crypto > acceleration hardware? > > > I looked at ecryptfs_encrypt_extent_done() and this made me think > > whether it should have special case for having -EBUSY and -EINPROGRESS. > > Looking at other ablkcipher callbacks, I'd think we'd at least need a > special case for -EINPROGRESS. > > > > > Sorry about bit coares "bug report" but I'm not expert either with > > ecryptfs or crypto implementation. > > No problem, thanks for bringing it to our attention! > > > Additionally, I just cc'ed you on a different patch that I have been > working as an alternative to the async patch. Maybe you can give it a > try, as well. > > Tyler > Email had 1 attachment: > + signature.asc > 1k (application/pgp-signature) -- To unsubscribe from this list: send the line "unsubscribe ecryptfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html