> As far as I can see, register access is not protected, how can your
> driver handle the case when dm-crypt and IPsec simultaneously try to
> encrypt/decrypt some data, it can happen even around
> preemt_disable/enable calls and actually crypto processing can happen
> in interrupt context too (although it is not the best thing to do).
I had the mutex in there, but I took it out based on our previous
conversations, which probably was a little rash. If CRYPTO_TFM_REQ_MAY_SLEEP
is still a valid flag to check, I could use that along with a spin lock of
some sort. I'll think about this a bit more.
> You added timeout for the broken hardware condition, I think it is
> better to return some error from _crypt() in that case, and, btw, that
> name is not very good choice.
I normally use _<blah> for static functions within my module - it helps
me remember which commands might be important to others and which are just
utility functions for my own use and abuse. I'll change the name.
Thanks,
Jordan
--
Jordan Crouse
Senior Linux Engineer
Advanced Micro Devices, Inc.
<http://www.amd.com/embeddedprocessors>
On Thu, Sep 28, 2006 at 10:31:15AM -0600, Jordan Crouse ([email protected]) wrote:
> > As far as I can see, register access is not protected, how can your
> > driver handle the case when dm-crypt and IPsec simultaneously try to
> > encrypt/decrypt some data, it can happen even around
> > preemt_disable/enable calls and actually crypto processing can happen
> > in interrupt context too (although it is not the best thing to do).
>
> I had the mutex in there, but I took it out based on our previous
> conversations, which probably was a little rash. If CRYPTO_TFM_REQ_MAY_SLEEP
> is still a valid flag to check, I could use that along with a spin lock of
> some sort. I'll think about this a bit more.
If it is set, then you can safely sleep there, but if it is not, it does
not always mean that sleeping is forbidden.
--
Evgeniy Polyakov