[Openswan Users] Netkey + Openswan + OCF && H/W accelerators drivers == kernel crash/panic

[David McCullough]

Jivin satpal parmar lays it down ...
> 
> 
> On Mon, Oct 17, 2011 at 10:21 AM, David McCullough <david_mccullough at mcafee.com> wrote:
> 
> 
> 
> 	Jivin satpal parmar lays it down ...
> 	
> 	...
> 	
> 	>       That's something for the driver writers or the kernel people....
> 	>
> 	>
> 	>
> 	> I made some progress in my investigation here. It seems there is a bug in driver (drivers/crypto/nss-sham.c)
> 	>
> 	>
> 	> static int nss_sham_update_cdma_start(struct nss_sham_dev *dd)
> 	> {
> 	>         struct nss_sham_reqctx *ctx = ahash_request_ctx(dd->req);
> 	>         unsigned int length, final, tail;
> 	>         struct scatterlist *sg;
> 	>
> 	>
> 	>         if (!ctx->total)
> 	>                 return 0;
> 	>
> 	>
> 	>         if (ctx->bufcnt || ctx->offset)
> 	>        return nss_sham_update_cdma_slow(dd); ---------------------->True for OCF/cryptodev/crptosoft path.This uses dma_single mapping instead of scatterlist.But in case of netkey/IPsec this is not true and we hit case
> 	>
> 	>
> 	>      if (!dma_map_sg(dd->dev, ctx->sg, 1, DMA_TO_DEVICE)) {
> 	>                 dev_err(dd->dev, "dma_map_sg  error\n");
> 	>                 return -EINVAL;
> 	>  which is scatter list DMA implementation and crashes in the end of this path (as seen in crash dump). I am yet to explore why we got two different paths and why it crashing but I think this is the right direction to investigate.
> 	>
> 	>
> 	> @David
> 	
> 	> I know its much to ask but if you can spare some time to see the code and confirm it would be great help. You can find code here. <http://processors.wiki.ti.com/index.php/Installing_AM389x_C6A816x_DM816x_Crypto_Support>
> 	
> 	cryptodev will only ever do single block requests (1 entry in the SG list).
> 	So that might explain the different paths.
> 	
> 
>  Ok! 
> 
> 
> 	It seems that for short/unaligned/other border cases that all processing is
> 	dne by the CPu and not the crypto HW,  so it may be that you are just not
> 	using the crypt HW ?  
> 
> In which case?  When I am testing H/W accelerators with cryptotest I can see visible drop in CPU usage from 97 % to 45 % so I assume H/W accelerator are working fine with OCF and cryptotest. In Netkey case Its crashing before I see debug info.

Sounds like its doing HW crypto then.

> 	Maybe if you changed the test with OCF you can still
> 	get it to fail as well ?
> 	
> 
> Will try this and update you. 

Try running openswan+klips+ocf too,  different usage to netkey might avoid
the problem.  Who knows.  It might also be easier for me to help you with
the driver issues with a crash from an openswan+klips+ocf call stack.

> 	Track the code through to where it fails, it might be obvious :-)
> 	
> 
> Yeah! going that way but I am dealing  many sub modules (openswan, ocf, cryapi, drivers) its hard to concentrate on one plus information on web on all is a real mess (limited, version problem, stale, incorrect) . Thanks to you guys I am able to make some progress. 

The nss drivers are the only code you need to analyse.

Trace the code through all its paths when netkey does it's ping to work out
why it fails.  If you can find the line of code it crashes on then I am
happy to see if I can spot a problem,  thats if you don't spot it yourself :-)

> 	Have you tried asking the Authors (herman at ti.com), seems they might be
> 	interested in helping you as well :-)
> 	
> Opened communication channel with TI. But that world is no Opensource.
> I know understand  what I mean :) 

Ok,  but they have published the code you are using now, it's just a matter
of finding someone who cares about that code and will help you.  Of course
that can be easier said than done ;-)

Cheers,
Davidm

-- 
David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org