Re: [PATCH] crypto: omap-sham: Fix Polling mode for larger blocks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Dec 18, 2013 at 07:03:33PM +0530, Lokesh Vutla wrote:
> Command "tcrypt sec=1 mode=403" give the follwoing error for Polling
> mode:
> root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403
> [...]
> 
> [  346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):   4352 opers/sec,  17825792 bytes/sec
> [  347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):   7095 opers/sec,  29061120 bytes/sec
> [  349.002667] test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates):
> [  349.010882] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [  349.020037] pgd = ddeac000
> [  349.022884] [00000000] *pgd=9dcb4831, *pte=00000000, *ppte=00000000
> [  349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM
> [  349.035482] Modules linked in: tcrypt(+)
> [  349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted 3.12.4-01566-g6279006-dirty #38
> [  349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000
> [  349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238
> [  349.058544] LR is at omap_sham_xmit_dma+0x38/0x238
> [  349.063570] pc : [<c04eb7cc>]    lr : [<c04eb798>]    psr: 20000013
> [  349.063570] sp : ddcd3c78  ip : 00000000  fp : 9d8980b8
> [  349.075610] r10: 00000000  r9 : 00000000  r8 : 00000000
> [  349.081090] r7 : 00001000  r6 : dd898000  r5 : 00000040  r4 : ddb10550
> [  349.087935] r3 : 00000004  r2 : 00000010  r1 : 53100080  r0 : 00000000
> [  349.094783] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> [  349.102268] Control: 10c5387d  Table: 9deac019  DAC: 00000015
> [  349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248)
> 
> [...]
> 
> This is because polling_mode is not enabled for ctx without FLAGS_FINUP.
> 
> For polling mode the bufcnt is made 0 unconditionally. But it should be made 0
> only if it is a final update or a total is not zero(This condition is similar
> to what is done in DMA case). Because of this wrong hashes are produced.
> 
> Fixing the same.
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla@xxxxxx>

Patch applied.  Thanks!
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux