On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote:
So far, the encryption/decryption are asynchronously processed in
softirq and cryptd which would result in a implicit order of data,
therefore leads IPSec stack also out of order while encapsulating
or decapsulating packets.
Consider
On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
Can't we just use cryptd unconditionally to fix this reordering problem?
I think the idea is that most of the time cryptd isn't required
so we want to stick with direct processing to lower latency.
I think the simplest fix would
On Wed, Nov 12, 2014 at 04:51:48PM +0800, Herbert Xu wrote:
On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
Can't we just use cryptd unconditionally to fix this reordering problem?
I think the idea is that most of the time cryptd isn't required
so we want to stick with
On 11/12/2014 04:51 PM, Herbert Xu wrote:
On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
Can't we just use cryptd unconditionally to fix this reordering problem?
I think the idea is that most of the time cryptd isn't required
so we want to stick with direct processing to
On 11/12/2014 04:41 PM, Steffen Klassert wrote:
On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote:
So far, the encryption/decryption are asynchronously processed in
softirq and cryptd which would result in a implicit order of data,
therefore leads IPSec stack also out of order while
On Wed, Nov 12, 2014 at 06:41:30PM +0800, Ming Liu wrote:
On 11/12/2014 04:51 PM, Herbert Xu wrote:
On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
Can't we just use cryptd unconditionally to fix this reordering problem?
I think the idea is that most of the time cryptd isn't
On Wed, Nov 12, 2014 at 06:41:28PM +0800, Ming Liu wrote:
On 11/12/2014 04:41 PM, Steffen Klassert wrote:
On Wed, Nov 12, 2014 at 01:49:31PM +0800, Ming Liu wrote:
}
@@ -147,11 +149,9 @@ static void cryptd_queue_worker(struct work_struct
*work)
preempt_disable();
backlog =
On Mon, Nov 10, 2014 at 11:50:36AM +0100, Ondrej Kozina wrote:
Hello,
could you please add this patch (already landed in 3.18-rc1) to following
stable kernels:
3.17.x, 3.14.x, 3.12.x, 3.4.x, 3.2.x?
Thank you, I'm also queuing it for the 3.16.
Cheers,
--
Luís
The bugfix allows usage
On Tue, Nov 11, 2014 at 05:36:16AM +0100, Stephan Mueller wrote:
Hi Herbert,
as discussed, these patches use the memzero_explicit function that is
yet to be integrated into the cryptodev-2.6 tree.
Stephan Mueller (2):
crypto: AF_ALG - zeroize message digest buffer
crypto: AF_ALG -
On Tue, Nov 11, 2014 at 04:18:13PM +0200, Catalin Vasile wrote:
Merge DES Cipher Block Chaining mode (CBC) and Triple DES Cipher Block
Chaining mode (CBC) algorithms from ablkcipher to givencrypt.
Signed-off-by: Catalin Vasile catalin.vas...@freescale.com
Applied.
--
Email: Herbert Xu
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback
Am Mittwoch, 12. November 2014, 17:15:52 schrieb Daniel Borkmann:
Hi Daniel,
thanks for the comments.
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
On 11/12/2014 05:54 PM, Stephan Mueller wrote:
Am Mittwoch, 12. November 2014, 17:15:52 schrieb Daniel Borkmann:
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
Am Mittwoch, 12. November 2014, 18:23:27 schrieb Daniel Borkmann:
Hi Daniel,
On 11/12/2014 05:54 PM, Stephan Mueller wrote:
Am Mittwoch, 12. November 2014, 17:15:52 schrieb Daniel Borkmann:
On 11/12/2014 08:05 AM, Stephan Mueller wrote:
This patch adds the random number generator support for
On 11/12/2014 06:46 PM, Stephan Mueller wrote:
...
* I unconditionally use the memset after memcpy as you indicated. Once
the cryptodev tree contains the memzero_explicit call, I will start
picking up that function.
Herbert merged it actually in this morning, so it's already part of
the
On 11/12/2014 07:43 PM, Steffen Klassert wrote:
On Wed, Nov 12, 2014 at 06:41:30PM +0800, Ming Liu wrote:
On 11/12/2014 04:51 PM, Herbert Xu wrote:
On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
Can't we just use cryptd unconditionally to fix this reordering problem?
I
16 matches
Mail list logo
