Re: crypto_shash_update & CRYPTO_TFM_REQ_MAY_SLEEP

[Dmitry Kasatkin <dmitry.kasatkin@nokia.com>]

Hi,

Alg code and drivers uses req/desc->flags to use GFP_KERNEL or GFP_ATOMIC.

crypto_kmap() -> Does not it make a sense to also use kmap/kmap_atomic
instead of just kmap_atomic()?

-----------------------------------
static inline void *crypto_kmap(struct page *page, int out)
{
    return kmap_atomic(page, crypto_kmap_type(out));
}
-------------------------------------------------

It is now not only about sync but also async code.
Would be nice to "wait" for hash completion in some cases...

What do you think?
What is the reason to have only kmap_atomic()?

- Dmitry


Kasatkin Dmitry (Nokia-D/Helsinki) wrote:
> Hi,
>
> Anyway, crypto driver is called with CRYPTO_TFM_REQ_MAY_SLEEP flag set.
> It basically mean it can sleep.
> But it is not because of kmap_atomic()
>
> So no possibility to know if to use GFP_KERNEL or GFP_ATOMIC.
>
> I guess that is not correct way.
>
> If driver cannot sleep then CRYPTO_TFM_REQ_MAY_SLEEP should not be set
> when calling it.
>
> Even sync implementation might use HW and sleep a bit while HW is doing
> calculation...
>
>
> - Dmitry
>
> ext Herbert Xu wrote:
>   
>> Dmitry Kasatkin <dmitry.kasatkin@nokia.com> wrote:
>>   
>>     
>>> One interesting issue
>>>
>>> Many clients in the kernel set CRYPTO_TFM_REQ_MAY_SLEEP to desc.flags.
>>> It is used by crypto_yeld().
>>>     
>>>       
>> That flag is really only meaningful for synchronous implementations.
>>
>> For hardware crypto that is asynchronous, you can simply ignore it
>> in most cases (exceptions include invoking a syncrhonous backup, for
>> example).
>>
>> Cheers,
>>   
>>     
> --
> To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>