async crashes

async crashes

[Jarkko Sakkinen]

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().

I looked at ecryptfs_encrypt_extent_done() and this made me think
whether it should have special case for having -EBUSY and -EINPROGRESS.

Sorry about bit coares "bug report" but I'm not expert either with
ecryptfs or crypto implementation.

Thanks.

/Jarkko

Re: async crashes

[Tyler Hicks]

[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: async crashes

[Jarkko Sakkinen]

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)