On Fri, 2013-11-29 at 09:50 +0800, Herbert Xu wrote:
On Thu, Nov 28, 2013 at 04:39:43PM +0100, Harald Freudenberger wrote:
You can't use mutex_lock because you may be in a non-sleepable
context. Perhaps just fall back to doing it block-by-block, like
we do in aesni-intel on x86?
On Tue, Nov 19, 2013 at 11:22:12AM +0100, Harald Freudenberger wrote:
The aes-ctr mode used one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this could lead to data corruption.
The patch introduces locking for the
On Thu, 2013-11-28 at 22:00 +0800, Herbert Xu wrote:
On Tue, Nov 19, 2013 at 11:22:12AM +0100, Harald Freudenberger wrote:
The aes-ctr mode used one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this could lead to data
On Thu, Nov 28, 2013 at 04:39:43PM +0100, Harald Freudenberger wrote:
You can't use mutex_lock because you may be in a non-sleepable
context. Perhaps just fall back to doing it block-by-block, like
we do in aesni-intel on x86?
The first attempt to lock the mutex is done with
On Tue, 19 Nov 2013 11:22:11 +0100
Harald Freudenberger fre...@linux.vnet.ibm.com wrote:
The aes-ctr mode used one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this could lead to data corruption.
The patch introduces
The aes-ctr mode used one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this could lead to data corruption.
The patch introduces locking for the preallocated page and alternatively
allocating and freeing of an temp page in
The aes-ctr mode used one preallocated page without any concurrency
protection. When multiple threads run aes-ctr encryption or decryption
this could lead to data corruption.
The patch introduces locking for the preallocated page and alternatively
allocating and freeing of an temp page in
