Hi, Herbert:
I've figured out a new patch for this issue reported by me previously,
the basic idea is adding a cryptd_flush_queue function fixing it by
being called from softirq to flush all previous queued elements before
processing a new one, and it works very well so far per my test, would
On Sun, Aug 03, 2014 at 05:57:06PM +0800, Ming Liu wrote:
>
> Please review this attached patch instead, the original one has a
> problem causing the kernel crash.
Thanks for the patch. I think it would better to enforce ordering
for all operations rather than treat encryptions separately from
d
On 07/31/2014 02:23 PM, Herbert Xu wrote:
On Thu, Jul 31, 2014 at 11:07:26AM +0800, Ming Liu wrote:
And we've figure out a patch as the attached, the basic idea is just
queue the packets if "irq_fpu_usable()" is not usable or if there
are already few packets queued for decryption. Else decrypt t
On 07/31/2014 02:23 PM, Herbert Xu wrote:
On Thu, Jul 31, 2014 at 11:07:26AM +0800, Ming Liu wrote:
And we've figure out a patch as the attached, the basic idea is just
queue the packets if "irq_fpu_usable()" is not usable or if there
are already few packets queued for decryption. Else decrypt t
On Thu, Jul 31, 2014 at 11:07:26AM +0800, Ming Liu wrote:
>
> And we've figure out a patch as the attached, the basic idea is just
> queue the packets if "irq_fpu_usable()" is not usable or if there
> are already few packets queued for decryption. Else decrypt the
> packets.
Yes your description m
Hi, all:
I encountered a IPsec packets reordering issue, following is the setup
and scenario
There is a IPSec IKEv1 tunnel between B & C
The traffic is UDP from C to A @ 40 mbps
Packets are coming in order at B but leaving out of order towards A
If IPSec is disabled between B &
