Re: [Ocf-linux-users] crypto_dispatch update for 20080917

[David M. <Dav...@se...>]

Jivin Kennedy, Brendan lays it down ...
> Thanks David,
> 
> So is that patch going to be in the next release? :-) Just it definitely
> changes how error cases need to be handled in the drivers...

If it fixes the problem you are seeing I will commit it and it will be in
the next release :-)  I should do one really,  it has the 2.6.29 updates
etc in there now and quite a few more little updates.

> Yep, it's EINVAL or EFAULT. The fault code seems to only matter if it's
> ERESTART though??

Basically I just wanted to know what a driver was doing that would return
an error other than full.  EINVAL sprang to mind if the kery sizes or
something similar didn't match.

I was concerned if it was something that would normally happen,  as I
haven't been seeing it myself.

Thanks again,

Cheers,
Davidm

> -----Original Message-----
> From: David McCullough [mailto:Dav...@se...] 
> Sent: 30 April 2009 00:03
> To: Kennedy, Brendan
> Cc: ocf...@li...
> Subject: Re: [Ocf-linux-users] crypto_dispatch update for 20080917
> 
> 
> Jivin Kennedy, Brendan lays it down ...
> > Hi All,
> > 
> > I am having trouble understanding the update to the crypto_dispatch function in crypto.c for ocf-linux-20080917 from ocf-linux-2071215:
> > 
> > 2007 code:
> >                 if (!cap->cc_qblocked) {
> >                         result = crypto_invoke(cap, crp, 0);
> >                         if (result != ERESTART)
> >                                 return (result);
> > 
> > 2008 code:
> >                         result = crypto_invoke(cap, crp, 0);
> >                         CRYPTO_Q_LOCK();
> >                         if (result != ERESTART)
> >                                 crypto_drivers[hid].cc_qblocked = 0;
> > 
> > In the 2008 code an error is not returned to cryptodev.c if crypto_invoke returns an error code.
> > Should we now always call crypto_done() if there is a fail in the driver invoke function?
> > 
> > I ask because I've tried this but am getting a soft lockup when using crypto-tools and testing some fail case scenarios if I set the crp->etype before calling crypto-done.
> 
> Yeah,  I can't explain it either and I made that change.  It was part of a
> SMP/locking problem and it looks like I lost the result code.  Here is a
> quick patch (untested :-) that I think will return the functionality that
> was lost.  Let me know how it goes.
> 
> Out of interest,  what is the condition error that the driver you are using
> is reporting ?  EINVAL perhaps ?
> 
> Thanks for tracking this down,
> 
> Cheers,
> Davidm
> 
> Index: ocf/crypto.c
> ===================================================================
> RCS file: ocf/crypto.c,v
> retrieving revision 1.42
> diff -u -r1.42 crypto.c
> --- ocf/crypto.c	31 Mar 2009 00:41:14 -0000	1.42
> +++ ocf/crypto.c	29 Apr 2009 23:01:08 -0000
> @@ -838,13 +838,15 @@
>  		 */
>  		list_add(&crp->crp_next, &crp_q);
>  		cryptostats.cs_blocks++;
> +		result = 0;
>  	} else if (result == -1) {
>  		TAILQ_INSERT_TAIL(&crp_q, crp, crp_next);
> +		result = 0;
>  	}
>  	if (crp_sleep)
>  		wake_up_interruptible(&cryptoproc_wait);
>  	CRYPTO_Q_UNLOCK();
> -	return 0;
> +	return result;
>  }
>  
>  /*
> 
> 
> -- 
> David McCullough,  dav...@se...,  Ph:+61 734352815
> McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org
> ---------------------------------------------------------------------
> Intel Shannon Limited
> Registered in Ireland
> Registered Office: One Spencer Dock, North Wall Quay, Dublin 1
> Registered Number: 308263
> Business address: Dromore House, East Park, Shannon, Co. Clare
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 

-- 
David McCullough,  dav...@se...,  Ph:+61 734352815
McAfee - SnapGear  http://www.snapgear.com                http://www.uCdot.org