CryptoAPI: schedual while atomic

CryptoAPI: schedual while atomic

[Jean-Luc Cooke]

While I was playing with using the CryptoAPI in /dev/random for my own
purposes, I noticed that I was getting quite a few "schedual while atomic!"
console messages.

Talking with Michal Ludvig, I seem to think that a "!is_atomic()" check
inside crypto_yield() or passing a flag during crypto_alloc_tfm() would make
a lot of sense.

This may be more directed at James Morris, but here it goes:

Can we have some logic to either check for or turn off crypto_yield()'s in
crypto/internal.h's crypto_yield() ?

Cheers,

JLC

Re: CryptoAPI: schedual while atomic

[James Morris]

On Mon, 30 Aug 2004, Jean-Luc Cooke wrote:

> While I was playing with using the CryptoAPI in /dev/random for my own
> purposes, I noticed that I was getting quite a few "schedual while atomic!"
> console messages.

Where is the code which caused this?  The transforms are safe to use (but
not allocate) in process and softirq contexts.

> Talking with Michal Ludvig, I seem to think that a "!is_atomic()" check
> inside crypto_yield() or passing a flag during crypto_alloc_tfm() would make
> a lot of sense.
> 
> This may be more directed at James Morris, but here it goes:
> 
> Can we have some logic to either check for or turn off crypto_yield()'s in
> crypto/internal.h's crypto_yield() ?

Why?  This should not be needed.


- James
-- 
James Morris
<jmorris@redhat.com>

Re: CryptoAPI: schedual while atomic

[Jean-Luc Cooke]

On Mon, Aug 30, 2004 at 10:42:11AM -0400, James Morris wrote:
> Where is the code which caused this?  The transforms are safe to use (but
> not allocate) in process and softirq contexts.

In add_entropy_words of random.c my experimental code is calling
crypto_digest_update().  In update() it calles crypto_yield.
add_entropy_words() is being call ed directly from a keyboard_interrupt.  I
was hoping to tidy up the code a bit by not using batch_entropy_stores... but
I guess that's unavoidable then?

Last question:
 Would spin_lock_irqsave() spin_unlock_irqrestore() still needed to surround
 crypto_digest_update() calls if they're going to be scattered/gathered
 later?

Thanks for your time.

JLC

Re: CryptoAPI: schedual while atomic

[James Morris]

On Mon, 30 Aug 2004, Jean-Luc Cooke wrote:

> On Mon, Aug 30, 2004 at 10:42:11AM -0400, James Morris wrote:
> > Where is the code which caused this?  The transforms are safe to use (but
> > not allocate) in process and softirq contexts.
> 
> In add_entropy_words of random.c my experimental code is calling
> crypto_digest_update().  In update() it calles crypto_yield.
> add_entropy_words() is being call ed directly from a keyboard_interrupt.  I
> was hoping to tidy up the code a bit by not using batch_entropy_stores... but
> I guess that's unavoidable then?

You can't call crypto routines from hardirq context.   Think about how 
slow crypto is and why you don't want it running in a hardware irq.


> Last question:
>  Would spin_lock_irqsave() spin_unlock_irqrestore() still needed to surround
>  crypto_digest_update() calls if they're going to be scattered/gathered
>  later?

Not sure exactly what you mean, but you need to serialize calls to 
crypto_digest_update(), yes.


- James
-- 
James Morris
<jmorris@redhat.com>