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
