CryptoAPI: schedual while atomic
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
Quoted 3 lines · Jean-Luc Cooke
While I was playing with using the CryptoAPI in
/dev/randomfor 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.
Quoted 8 lines
Talking with Michal Ludvig, I seem to think that a "!is_atomic()" check inside
crypto_yield()or passing a flag duringcrypto_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
Signature · 2 lines
James Morris <[email protected]>
Quoted 2 lines · James Morris
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
Quoted 9 lines · Jean-Luc Cooke
Quoted 2 lines · James Morris
Where is the code which caused this? The transforms are safe to use (but not allocate) in process and softirq contexts.
In
add_entropy_wordsofrandom.cmy experimental code is callingcrypto_digest_update(). Inupdate()it callescrypto_yield.add_entropy_words()is being call ed directly from akeyboard_interrupt. I was hoping to tidy up the code a bit by not usingbatch_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.
Quoted 4 lines
Last question:
Wouldspin_lock_irqsave()spin_unlock_irqrestore()still needed to surroundcrypto_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
Signature · 2 lines
James Morris <[email protected]>