Bug#552270: Marvell CESA driver and Kirkwood

Bug#552270: Marvell CESA driver and Kirkwood

[L.C.]

Gentlemen,

I understand from Martin Michmayr you are maintainers of the module, so 
I'm reporting you this.

mv_cesa when enabled on Kirkwood always causes an OOPS whenever openswan 
tries to use the AES module. I'm talking about 2.6.32.

I saw no problems anymore with mv_cesa disabled or blacklisted. Here 
comes the trace.

Cheers, L.C.

--------------cut
[   75.000907] alg: No test for authenc(hmac(sha1),cbc(aes)) 
(authenc(hmac(sha1-generic),mv-cbc-aes))
[   82.634680] Unable to handle kernel paging request at virtual address 
e0000004
[   82.641968] pgd = deb84000
[   82.644689] [e0000004] *pgd=00000000
[   82.648293] Internal error: Oops: 5 [#1]
[   82.652232] last sysfs file: /sys/module/aes_generic/initstate
[   82.658091] Modules linked in: authenc ctr camellia cast5 rmd160 
sha1_generic hmac crypto_null ccm serpent blowfish twofish 
twofish_common ecb xcbc cbc sha256_generic sha512_generic des_generic 
xfrm_user ah6 ah4 esp6 esp4 xfrm4_mode_beet xfrm4_tunnel tunnel4 
xfrm4_mode_tunnel xfrm4_mode_transport xfrm6_mode_transport 
xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel ipcomp ipcomp6 
xfrm_ipcomp xfrm6_tunnel tunnel6 af_key tun ipv6 ext2 loop mv_cesa 
aes_generic ext3 jbd mbcache mmc_block ehci_hcd mvsdio mv643xx_eth 
usbcore mmc_core nls_base libphy
[   82.706822] CPU: 0    Not tainted  (2.6.32-trunk-kirkwood #1)
[   82.712609] PC is at queue_manag+0x230/0x2b0 [mv_cesa]
[   82.717778] LR is at queue_manag+0x220/0x2b0 [mv_cesa]
[   82.722937] pc : [<bf0d69fc>]    lr : [<bf0d69ec>]    psr: a0000013
[   82.722943] sp : c086dfb0  ip : 00000000  fp : 00000000
[   82.734480] r10: bf0d6f48  r9 : 00000000  r8 : 00000001
[   82.739730] r7 : c086c000  r6 : bf0d6f48  r5 : a1c1d680  r4 : df9de460
[   82.746288] r3 : 00000048  r2 : 000621a3  r1 : df9de5c8  r0 : dffffff8
[   82.752846] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
Segment kernel
[   82.760188] Control: 0005397f  Table: 1eb84000  DAC: 00000017
[   82.765959] Process mv_crypto (pid: 241, stack limit = 0xc086c270)
[   82.772168] Stack: (0xc086dfb0 to 0xc086e000)
[   82.776549] dfa0:                                     c086dfd4 
deb3be6c de937480 bf0d67cc
[   82.784765] dfc0: 00000000 00000000 00000000 c005be04 00000000 
00000000 c086dfd8 c086dfd8
[   82.792987] dfe0: 00000000 00000000 00000000 00000000 00000000 
c0027e7c 00000000 00000000
[   82.801233] [<bf0d69fc>] (queue_manag+0x230/0x2b0 [mv_cesa]) from 
[<c005be04>] (kthread+0x78/0x80)
[   82.810241] [<c005be04>] (kthread+0x78/0x80) from [<c0027e7c>] 
(kernel_thread_exit+0x0/0x8)
[   82.818633] Code: e5941020 e5945018 e3a02000 e1a00001 (e590300c)
[   82.824879] ---[ end trace 1206762c21c134f8 ]---
--------------cut


  Bug#552270: Marvell CESA driver and Kirkwood

Martin Michlmayr
Tue, 27 Oct 2009 13:54:11 -0700

I got the following answer, so I'll go ahead and enable CESA for
Kirkwood.

* Sebastian Andrzej Siewior<sebast...@breakpoint.cc>  [2009-10-26 22:53]:
>  * Martin Michlmayr | 2009-10-26 18:26:08 [+0800]:
>
>  >Hi Sebastian and Nico,
>  Hi Martin,
>
>  >I put Sebastian's CESA driver into Debian's 2.6.31 kernel and enabled
>  >it for orion5x.  A Debian user asked me why I didn't enable it for
>  >Kirkwood.  AFAIK, there are some differences between the CESA on
>  >Orion5x and Kirkwood, so my assumption was that the current CESA
>  >driver doesn't work on Kirkwood.  But I'm actually not sure if this is
>  >true.
>  >
>  >Do you know if the current driver will work on Kirkwood?
>  I don't really know. I just looked through the spec and compared them
>  and they look very alike:
>  - Orion's has larger sram space. The driver does not assume, it uses the
>    size specified and Kirkwood's is set to 2KiB
>  - the register seem to be at the same spot. Orion has two engines,
>    Kirkwood just one. Right now, only the first one is used.
>  - security engine's descriptor looks the same
>  - the DMA engine differs in a few spot but it is not yet implemented so
>    it doesn't matter.
>
>  As far as I can see in current git, Nico enabled the CESA engine on
>  Kirkwood [0]. It looks like he assumes that it should work, I don't know
>  if he ever has tested it :)
>
>  [0]
>  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ae5c8c83735f5fcb09b380944e4854a383006998
>  Sebastian


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20100418/b521b34a/attachment.htm>

Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* L.C. | 2010-04-18 19:23:21 [+0200]:

>mv_cesa when enabled on Kirkwood always causes an OOPS whenever
>openswan tries to use the AES module. I'm talking about 2.6.32.
Hmm. I've never tried IPsec. Is it possible to for you test the
cryptodev git tree [0] ? There were a few patches flying by solving an
issue where I did not walk correctly through the scatterlist your
backtrace kinda looks like this could be the issue here.

[0] http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=summary

Sebastian

Bug#552270: Marvell CESA driver and Kirkwood

[L.C.]

Tested with 
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git. 
(2.6.33, identical config als the previous 2.6.32)

Although up to 2.6.32 (2.6.32-3 in debian) I got still a recoverable 
OOPS (by removing mv_cesa), with the 2.6.33 cryptodev I get an 
unrecoverable OOPS where the all system hangs. Nasty.

This happens in exactly the same conditions as before (when the ipsec 
connection is estabilished through AES and SHA1 and some traffic tries 
that way. Last row before the crash:
[   41.799083] alg: No test for authenc(hmac(sha1),cbc(aes)) 
(authenc(mvhmac-sha1,mv-cbc-aes))


I'd get the trace via console (of little use really, I guess) or later 
try debug recompile to get some more clue (it will take some time though).

L.

On 18/04/2010 21:17, Sebastian Andrzej Siewior wrote:
> * L.C. | 2010-04-18 19:23:21 [+0200]:
>
>    
>> mv_cesa when enabled on Kirkwood always causes an OOPS whenever
>> openswan tries to use the AES module. I'm talking about 2.6.32.
>>      
> Hmm. I've never tried IPsec. Is it possible to for you test the
> cryptodev git tree [0] ? There were a few patches flying by solving an
> issue where I did not walk correctly through the scatterlist your
> backtrace kinda looks like this could be the issue here.
>
> [0] http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=summary
>
> Sebastian
>    

Bug#552270: Marvell CESA driver and Kirkwood

[L.C.]

Sebastian, here is the OOPS from the latest cryptodev git tree (2.6.33), 
more clue than I thought, it looks?:

------------------------------------cut
flip> ping 10.10.10.230
PING 10.10.10.23[51252.081262] Unable to handle kernel NULL pointer 
dereference at virtual address 00000034
0 (10.10.10.230)[51252.090530] pgd = c0004000
  56(84) bytes of[51252.094632] [00000034] *pgd=00000000 data.

[51252.100326] Internal error: Oops: 17 [#1]
[51252.104351] last sysfs file: /sys/module/ccm/initstate
[51252.109514] Modules linked in: xfrm_user ah6 ah4 esp6 esp4 
xfrm4_mode_beet xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport 
xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel 
ipcomp ipcomp6 xfrm6_tunnel af_key mv_cesa authenc ctr camellia cast5 
rmd160 crypto_null ccm serpent blowfish twofish twofish_common ecb xcbc 
cbc sha256_generic sha512_generic des_generic tunnel4 xfrm_ipcomp 
tunnel6 autofs4 8021q garp stp ipv6 ext2 loop hmac sha1_generic 
aes_generic ext3 jbd mbcache mmc_block ehci_hcd mvsdio usbcore 
mv643xx_eth mmc_core nls_base libphy [last unloaded: af_key]
[51252.162037] CPU: 0    Not tainted  (2.6.33 #1)
[51252.166509] PC is at xfrm_output_resume+0x140/0x35c
[51252.171419] LR is at authenc_geniv_ahash_done+0x4c/0x50 [authenc]
[51252.177541] pc : [<c02a207c>]    lr : [<bf2872e8>]    psr: 60000013
[51252.177547] sp : c086bf48  ip : 00000014  fp : 00000178
[51252.189084] r10: 00000170  r9 : df4a7618  r8 : 00000000
[51252.194334] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : df4a7600
[51252.200891] r3 : 00000000  r2 : df621800  r1 : 00000000  r0 : df4a7600
[51252.207449] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  
Segment kernel
[51252.214791] Control: 0005397f  Table: 0097c000  DAC: 00000017
[51252.220564] Process mv_crypto (pid: 4702, stack limit = 0xc086a270)
[51252.226860] Stack: (0xc086bf48 to 0xc086c000)
[51252.231242] bf40:                   0000000c c017f364 c086bf60 
df6218a8 000008ac c017f548
[51252.239465] bf60: df621800 df621840 00000000 bf2a8d90 def796c0 
df6218f8 c086a000 00000000
[51252.247688] bf80: def796ec bf2872e8 00000001 00000000 00000100 
00000000 00000078 bf2a814c
[51252.255912] bfa0: def796c0 def796ec a0000013 dfeede58 c086bfd4 
bf2a7fe4 def796c0 00000000
[51252.264134] bfc0: 00000000 00000000 00000000 c005a848 00000000 
00000000 c086bfd8 c086bfd8
[51252.272356] bfe0: 00000000 00000000 00000000 00000000 00000000 
c0026dec 00000000 00000000
[51252.280591] [<c02a207c>] (xfrm_output_resume+0x140/0x35c) from 
[<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50 [authenc])
[51252.291709] [<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50 
[authenc]) from [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa])
[51252.303082] [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa]) from 
[<c005a848>] (kthread+0x78/0x80)
[51252.312091] [<c005a848>] (kthread+0x78/0x80) from [<c0026dec>] 
(kernel_thread_exit+0x0/0x8)
[51252.320483] Code: e1a06000 ea00007f e5947048 e3560000 (e5975034)
[51252.326631] ---[ end trace 0fd0f54982ede5bf ]---
[51252.331284] Kernel panic - not syncing: Fatal exception in interrupt
[51252.337690] [<c002be44>] (unwind_backtrace+0x0/0xd8) from 
[<c02b2be0>] (panic+0x40/0x120)
[51252.345914] [<c02b2be0>] (panic+0x40/0x120) from [<c0029b24>] 
(die+0x2d4/0x32c)
[51252.353277] [<c0029b24>] (die+0x2d4/0x32c) from [<c002cc98>] 
(__do_kernel_fault+0x64/0x88)
[51252.361603] [<c002cc98>] (__do_kernel_fault+0x64/0x88) from 
[<c002cee8>] (do_page_fault+0x22c/0x248)
[51252.370792] [<c002cee8>] (do_page_fault+0x22c/0x248) from 
[<c002527c>] (do_DataAbort+0x34/0x94)
[51252.379545] [<c002527c>] (do_DataAbort+0x34/0x94) from [<c00259ec>] 
(__dabt_svc+0x4c/0x60)
[51252.387857] Exception stack(0xc086bf00 to 0xc086bf48)
[51252.392949] bf00: df4a7600 00000000 df621800 00000000 df4a7600 
00000000 00000000 00000000
[51252.401180] bf20: 00000000 df4a7618 00000170 00000178 00000014 
c086bf48 bf2872e8 c02a207c
[51252.409404] bf40: 60000013 ffffffff
[51252.412920] [<c00259ec>] (__dabt_svc+0x4c/0x60) from [<c02a207c>] 
(xfrm_output_resume+0x140/0x35c)
[51252.421941] [<c02a207c>] (xfrm_output_resume+0x140/0x35c) from 
[<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50 [authenc])
[51252.433064] [<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50 
[authenc]) from [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa])
[51252.444450] [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa]) from 
[<c005a848>] (kthread+0x78/0x80)
[51252.453468] [<c005a848>] (kthread+0x78/0x80) from [<c0026dec>] 
(kernel_thread_exit+0x0/0x8)
--------------------------------------------cut


On 18/04/2010 21:17, Sebastian Andrzej Siewior wrote:
> * L.C. | 2010-04-18 19:23:21 [+0200]:
>
>    
>> mv_cesa when enabled on Kirkwood always causes an OOPS whenever
>> openswan tries to use the AES module. I'm talking about 2.6.32.
>>      
> Hmm. I've never tried IPsec. Is it possible to for you test the
> cryptodev git tree [0] ? There were a few patches flying by solving an
> issue where I did not walk correctly through the scatterlist your
> backtrace kinda looks like this could be the issue here.
>
> [0] http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=summary
>
> Sebastian
>    

Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* L.C. | 2010-04-20 22:45:19 [+0200]:

>Sebastian, here is the OOPS from the latest cryptodev git tree
>(2.6.33), more clue than I thought, it looks?:

No I don't. I look at it this weekend. I need just to setup IPsec in
order to reproduce this, right?

>------------------------------------cut
>flip> ping 10.10.10.230
>PING 10.10.10.23[51252.081262] Unable to handle kernel NULL pointer
>dereference at virtual address 00000034
>0 (10.10.10.230)[51252.090530] pgd = c0004000
> 56(84) bytes of[51252.094632] [00000034] *pgd=00000000 data.
>
>[51252.100326] Internal error: Oops: 17 [#1]
>[51252.104351] last sysfs file: /sys/module/ccm/initstate
>[51252.109514] Modules linked in: xfrm_user ah6 ah4 esp6 esp4
>xfrm4_mode_beet xfrm4_tunnel xfrm4_mode_tunnel xfrm4_mode_transport
>xfrm6_mode_transport xfrm6_mode_ro xfrm6_mode_beet xfrm6_mode_tunnel
>ipcomp ipcomp6 xfrm6_tunnel af_key mv_cesa authenc ctr camellia cast5
>rmd160 crypto_null ccm serpent blowfish twofish twofish_common ecb
>xcbc cbc sha256_generic sha512_generic des_generic tunnel4
>xfrm_ipcomp tunnel6 autofs4 8021q garp stp ipv6 ext2 loop hmac
>sha1_generic aes_generic ext3 jbd mbcache mmc_block ehci_hcd mvsdio
>usbcore mv643xx_eth mmc_core nls_base libphy [last unloaded: af_key]
>[51252.162037] CPU: 0    Not tainted  (2.6.33 #1)
>[51252.166509] PC is at xfrm_output_resume+0x140/0x35c
>[51252.171419] LR is at authenc_geniv_ahash_done+0x4c/0x50 [authenc]
>[51252.177541] pc : [<c02a207c>]    lr : [<bf2872e8>]    psr: 60000013
>[51252.177547] sp : c086bf48  ip : 00000014  fp : 00000178
>[51252.189084] r10: 00000170  r9 : df4a7618  r8 : 00000000
>[51252.194334] r7 : 00000000  r6 : 00000000  r5 : 00000000  r4 : df4a7600
>[51252.200891] r3 : 00000000  r2 : df621800  r1 : 00000000  r0 : df4a7600
>[51252.207449] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM
>Segment kernel
>[51252.214791] Control: 0005397f  Table: 0097c000  DAC: 00000017
>[51252.220564] Process mv_crypto (pid: 4702, stack limit = 0xc086a270)
>[51252.226860] Stack: (0xc086bf48 to 0xc086c000)
>[51252.231242] bf40:                   0000000c c017f364 c086bf60
>df6218a8 000008ac c017f548
>[51252.239465] bf60: df621800 df621840 00000000 bf2a8d90 def796c0
>df6218f8 c086a000 00000000
>[51252.247688] bf80: def796ec bf2872e8 00000001 00000000 00000100
>00000000 00000078 bf2a814c
>[51252.255912] bfa0: def796c0 def796ec a0000013 dfeede58 c086bfd4
>bf2a7fe4 def796c0 00000000
>[51252.264134] bfc0: 00000000 00000000 00000000 c005a848 00000000
>00000000 c086bfd8 c086bfd8
>[51252.272356] bfe0: 00000000 00000000 00000000 00000000 00000000
>c0026dec 00000000 00000000
>[51252.280591] [<c02a207c>] (xfrm_output_resume+0x140/0x35c) from
>[<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50 [authenc])
>[51252.291709] [<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50
>[authenc]) from [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa])
>[51252.303082] [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa]) from
>[<c005a848>] (kthread+0x78/0x80)
>[51252.312091] [<c005a848>] (kthread+0x78/0x80) from [<c0026dec>]
>(kernel_thread_exit+0x0/0x8)
>[51252.320483] Code: e1a06000 ea00007f e5947048 e3560000 (e5975034)
>[51252.326631] ---[ end trace 0fd0f54982ede5bf ]---
>[51252.331284] Kernel panic - not syncing: Fatal exception in interrupt
>[51252.337690] [<c002be44>] (unwind_backtrace+0x0/0xd8) from
>[<c02b2be0>] (panic+0x40/0x120)
>[51252.345914] [<c02b2be0>] (panic+0x40/0x120) from [<c0029b24>]
>(die+0x2d4/0x32c)
>[51252.353277] [<c0029b24>] (die+0x2d4/0x32c) from [<c002cc98>]
>(__do_kernel_fault+0x64/0x88)
>[51252.361603] [<c002cc98>] (__do_kernel_fault+0x64/0x88) from
>[<c002cee8>] (do_page_fault+0x22c/0x248)
>[51252.370792] [<c002cee8>] (do_page_fault+0x22c/0x248) from
>[<c002527c>] (do_DataAbort+0x34/0x94)
>[51252.379545] [<c002527c>] (do_DataAbort+0x34/0x94) from
>[<c00259ec>] (__dabt_svc+0x4c/0x60)
>[51252.387857] Exception stack(0xc086bf00 to 0xc086bf48)
>[51252.392949] bf00: df4a7600 00000000 df621800 00000000 df4a7600
>00000000 00000000 00000000
>[51252.401180] bf20: 00000000 df4a7618 00000170 00000178 00000014
>c086bf48 bf2872e8 c02a207c
>[51252.409404] bf40: 60000013 ffffffff
>[51252.412920] [<c00259ec>] (__dabt_svc+0x4c/0x60) from [<c02a207c>]
>(xfrm_output_resume+0x140/0x35c)
>[51252.421941] [<c02a207c>] (xfrm_output_resume+0x140/0x35c) from
>[<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50 [authenc])
>[51252.433064] [<bf2872e8>] (authenc_geniv_ahash_done+0x4c/0x50
>[authenc]) from [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa])
>[51252.444450] [<bf2a814c>] (queue_manag+0x168/0x4f0 [mv_cesa]) from
>[<c005a848>] (kthread+0x78/0x80)
>[51252.453468] [<c005a848>] (kthread+0x78/0x80) from [<c0026dec>]
>(kernel_thread_exit+0x0/0x8)
>--------------------------------------------cut

Sebastian

Bug#552270: Marvell CESA driver and Kirkwood

[Uri Simchoni]

I have some IPSec background but am not familiar with the Linux implementation (I'm using the mv_cesa for SSL acceleration through a usermode interface I'm working on). Can you point me to the nearest howto? I suppose I could have a look.
Thanks,
Uri.

On 4/21/2010 11:13 AM, Sebastian Andrzej Siewior wrote:
> * L.C. | 2010-04-20 22:45:19 [+0200]:
> 
>> Sebastian, here is the OOPS from the latest cryptodev git tree
>> (2.6.33), more clue than I thought, it looks?:
> 
> No I don't. I look at it this weekend. I need just to setup IPsec in
> order to reproduce this, right?
> 
>> ------------------------------------cut
>> flip> ping 10.10.10.230
>> PING 10.10.10.23[51252.081262] Unable to handle kernel NULL pointer
>> dereference at virtual address 00000034
>> 0 (10.10.10.230)[51252.090530] pgd = c0004000
>> 56(84) bytes of[51252.094632] [00000034] *pgd=00000000 data.
>>
<snip>
> 
> Sebastian
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Sebastian Andrzej Siewior]

a driver might drop EINPROGRESS because its internal queue is full and
not because something went wrong. In that case there will be another
call back invocation and the stack should not free the skb.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
---
 net/xfrm/xfrm_output.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index 6a32915..34dd460 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -86,10 +86,10 @@ static int xfrm_output_one(struct sk_buff *skb, int err)
 		spin_unlock_bh(&x->lock);
 
 		err = x->type->output(x, skb);
+resume:
 		if (err == -EINPROGRESS)
 			goto out_exit;
 
-resume:
 		if (err) {
 			XFRM_INC_STATS(net, LINUX_MIB_XFRMOUTSTATEPROTOERROR);
 			goto error_nolock;
-- 
1.6.6.1

Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* Uri Simchoni | 2010-04-22 06:23:12 [+0300]:

>I have some IPSec background but am not familiar with the Linux implementation (I'm using the mv_cesa for SSL acceleration through a usermode interface I'm working on). Can you point me to the nearest howto? I suppose I could have a look.

If it is possible, please post some patches which describe the user land
interface.

For IPSec I use this[0] shell script which sets up a connection. Good for
testing :) So you need two boxes, start the script on both machines and
the first ping that reached my orion box triggered that error. I just
sent something that looked like a fix.

I enabled list and sg debugging and a flood ping triggered a couple of
warning. Could you please look at this?

IPsec requests authenc(hmac(sha1),cbc(aes)) so right now it reqeusts two
cesa provided algorithms. A single ping results in around 30ms RTT.
Disabling hmac(sha1) gives me less than 1ms.
Implementing authenc() for IPsec should speed things up. Right I'm stuck
with hacking DMA support.

For now I think lowering priority of hmac() should fix the problem. A
direct request "mv-hmac-sha1" should still returned the mv driver. What
do you thing?

Need to run now....

>Thanks,
>Uri.

Sebastian

Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* Sebastian Andrzej Siewior | 2010-04-24 17:12:07 [+0200]:

>For IPSec I use this[0] shell script which sets up a connection. Good for
[0] http://breakpoint.cc/ipsec.sh

Sebastian

Bug#552270: Marvell CESA driver and Kirkwood

[Uri Simchoni]

On 4/24/2010 6:12 PM, Sebastian Andrzej Siewior wrote:
> * Uri Simchoni | 2010-04-22 06:23:12 [+0300]:
> 
> For IPSec I use this[0] shell script which sets up a connection. Good for
> testing :) 
Thanks, That'll save time setting it up...
> I enabled list and sg debugging and a flood ping triggered a couple of
> warning. Could you please look at this?
Sure.
> 
> IPsec requests authenc(hmac(sha1),cbc(aes)) so right now it reqeusts two
> cesa provided algorithms. A single ping results in around 30ms RTT.
Since the CESA does each operation faster than sw (at least when the packet size exceeds some threshold), I see no reason for it to slow the process down. The slowness probably is somehow caused by the same thing that causes the oops, or by debug warning prints.

> Disabling hmac(sha1) gives me less than 1ms.
> Implementing authenc() for IPsec should speed things up. Right I'm stuck
> with hacking DMA support.
Well, so far I wasn't able to figure out how it all fits together - sure, the CESA can do AES-CBC+HMAC-SHA1 in one run, but I'm not sure it's suitable for IPSec, or that the crypto infrastructure supports a HW driver for combined operation. (the CESA is probably not suitable for SSL because of alignment problems, IPSec is better in that respect).
> 
> For now I think lowering priority of hmac() should fix the problem. A
> direct request "mv-hmac-sha1" should still returned the mv driver. What
> do you thing?
> 
I think there's a bug here I should find and fix. Till then perhaps the mv-hmac-sha1 driver should not be registered at all.
> Need to run now....
> 
>> Thanks,
>> Uri.
> 
> Sebastian

[PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Herbert Xu]

On Sat, Apr 24, 2010 at 04:42:15PM +0200, Sebastian Andrzej Siewior wrote:
> a driver might drop EINPROGRESS because its internal queue is full and
> not because something went wrong. In that case there will be another
> call back invocation and the stack should not free the skb.
> 
> Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

This should only be possible when we use the MAY_BACKLOG flag,
as otherwise EINPROGRESS should never be used on the completion
function unless it's a real error.

Which algorithm is generating EINPROGRESS in this case?

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Sebastian Andrzej Siewior]

* Herbert Xu | 2010-04-25 09:18:21 [+0800]:

>This should only be possible when we use the MAY_BACKLOG flag,
>as otherwise EINPROGRESS should never be used on the completion
>function unless it's a real error.
Urgh, right. I think I lost it.

>Which algorithm is generating EINPROGRESS in this case?
The call stack looks like the following:

  crypto_authenc_givencrypt_done()
   \crypto_authenc_ahash
    \crypto_ahash_digest()
     \mv_hash_digest()
      \crypto_enqueue_request() <= -EINPROGRESS
  crypto_authenc_givencrypt_done() err is EINPROGRESS
   \aead_request_complete()
    \xfrm_output_resume()

So I get in xfrm_output_one() with err == -EINPROGRESS. Now, that one
gets survided. The segfault happens later when xfrm_output_one() is
called with err = 0 for the same skb. The segfaults happens during 
   x = dst->xfrm;
is executed.

>Thanks,
>-- 

Sebastian

[PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Herbert Xu]

On Sun, Apr 25, 2010 at 05:29:28PM +0200, Sebastian Andrzej Siewior wrote:
> * Herbert Xu | 2010-04-25 09:18:21 [+0800]:
> 
> >This should only be possible when we use the MAY_BACKLOG flag,
> >as otherwise EINPROGRESS should never be used on the completion
> >function unless it's a real error.
> Urgh, right. I think I lost it.
> 
> >Which algorithm is generating EINPROGRESS in this case?
> The call stack looks like the following:
> 
>   crypto_authenc_givencrypt_done()
>    \crypto_authenc_ahash
>     \crypto_ahash_digest()
>      \mv_hash_digest()
>       \crypto_enqueue_request() <= -EINPROGRESS

OK that was my fault.  Steffen had all the requisite EINPROGRESS
checks in place but I told him to get rid of them.

This patch should fix it.

commit 180ce7e81030e1ef763d58f97f9ab840ff57d848
Author: Herbert Xu <herbert@gondor.apana.org.au>
Date:   Mon Apr 26 09:14:05 2010 +0800

    crypto: authenc - Add EINPROGRESS check
    
    When Steffen originally wrote the authenc async hash patch, he
    correctly had EINPROGRESS checks in place so that we did not invoke
    the original completion handler with it.
    
    Unfortuantely I told him to remove it before the patch was applied.
    
    As only MAY_BACKLOG request completion handlers are required to
    handle EINPROGRESS completions, those checks are really needed.
    
    This patch restores them.
    
    Reported-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
    Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

diff --git a/crypto/authenc.c b/crypto/authenc.c
index 2bb7348..05eb32e 100644
--- a/crypto/authenc.c
+++ b/crypto/authenc.c
@@ -46,6 +46,12 @@ struct authenc_request_ctx {
 	char tail[];
 };
 
+static void authenc_request_complete(struct aead_request *req, int err)
+{
+	if (err != -EINPROGRESS)
+		aead_request_complete(req, err);
+}
+
 static int crypto_authenc_setkey(struct crypto_aead *authenc, const u8 *key,
 				 unsigned int keylen)
 {
@@ -142,7 +148,7 @@ static void authenc_geniv_ahash_update_done(struct crypto_async_request *areq,
 				 crypto_aead_authsize(authenc), 1);
 
 out:
-	aead_request_complete(req, err);
+	authenc_request_complete(req, err);
 }
 
 static void authenc_geniv_ahash_done(struct crypto_async_request *areq, int err)
@@ -208,7 +214,7 @@ static void authenc_verify_ahash_update_done(struct crypto_async_request *areq,
 	err = crypto_ablkcipher_decrypt(abreq);
 
 out:
-	aead_request_complete(req, err);
+	authenc_request_complete(req, err);
 }
 
 static void authenc_verify_ahash_done(struct crypto_async_request *areq,
@@ -245,7 +251,7 @@ static void authenc_verify_ahash_done(struct crypto_async_request *areq,
 	err = crypto_ablkcipher_decrypt(abreq);
 
 out:
-	aead_request_complete(req, err);
+	authenc_request_complete(req, err);
 }
 
 static u8 *crypto_authenc_ahash_fb(struct aead_request *req, unsigned int flags)
@@ -379,7 +385,7 @@ static void crypto_authenc_encrypt_done(struct crypto_async_request *req,
 		err = crypto_authenc_genicv(areq, iv, 0);
 	}
 
-	aead_request_complete(areq, err);
+	authenc_request_complete(areq, err);
 }
 
 static int crypto_authenc_encrypt(struct aead_request *req)
@@ -420,7 +426,7 @@ static void crypto_authenc_givencrypt_done(struct crypto_async_request *req,
 		err = crypto_authenc_genicv(areq, greq->giv, 0);
 	}
 
-	aead_request_complete(areq, err);
+	authenc_request_complete(areq, err);
 }
 
 static int crypto_authenc_givencrypt(struct aead_givcrypt_request *req)

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Sebastian Andrzej Siewior]

* Herbert Xu | 2010-04-26 09:17:11 [+0800]:

>OK that was my fault.  Steffen had all the requisite EINPROGRESS
>checks in place but I told him to get rid of them.
>
>This patch should fix it.
Excellent job Herbert, it does solve the problem.

Sebastian

[PATCH] net/ipsec: don't treat EINPROGRESS as a regular error

[Herbert Xu]

On Mon, Apr 26, 2010 at 08:11:42PM +0200, Sebastian Andrzej Siewior wrote:
>
> Excellent job Herbert, it does solve the problem.

Thanks for testing.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Bug#552270: Marvell CESA driver and Kirkwood

[Sebastian Andrzej Siewior]

* Uri Simchoni | 2010-04-24 21:43:35 [+0300]:

Sorry for the late reply.

>> I enabled list and sg debugging and a flood ping triggered a couple of
>> warning. Could you please look at this?
>Sure.
It seems that everything is working now.

>> IPsec requests authenc(hmac(sha1),cbc(aes)) so right now it reqeusts two
>> cesa provided algorithms. A single ping results in around 30ms RTT.
>Since the CESA does each operation faster than sw (at least when the packet size exceeds some threshold), I see no reason for it to slow the process down. The slowness probably is somehow caused by the same thing that causes the oops, or by debug warning prints.
Yup looks like it.

>> Disabling hmac(sha1) gives me less than 1ms.
>> Implementing authenc() for IPsec should speed things up. Right I'm stuck
>> with hacking DMA support.
>Well, so far I wasn't able to figure out how it all fits together - sure, the CESA can do AES-CBC+HMAC-SHA1 in one run, but I'm not sure it's suitable for IPSec, or that the crypto infrastructure supports a HW driver for combined operation. (the CESA is probably not suitable for SSL because of alignment problems, IPSec is better in that respect).

It does, AEAD is just for this purpose. The FSL talitos driver does
this. Not sure if it is the only one.
I try to hack DMA support before I focus on this.
 
>>> Thanks,
>>> Uri.

Sebastian