On Tue, Jan 27, 2009 at 09:01:13PM +0300, Andrey Borzenkov wrote:
>
> - all usage is kmap_atomic; which implies it should be technically safe
> (not advisable) to use in interrupt context as well
kmap_atomic has limited slots, we currently use two slots for
process context and two slots for soft
On 24 января 2009 12:32:45 Herbert Xu wrote:
> Andrey Borzenkov wrote:
> > On 24 января 2009 01:31:50 Herbert Xu wrote:
> >> 2) The highmem primitives we use are currently softirq only. We
> >> could make them work for hardirq as well, but because of 1) we
> >> didn't.
> >
> > Could you point to
Andrey Borzenkov wrote:
>
> On 24 января 2009 01:31:50 Herbert Xu wrote:
>>
>> 2) The highmem primitives we use are currently softirq only. We
>> could make them work for hardirq as well, but because of 1) we
>> didn't.
>
> Could you point to example of such primitive in code under crypto?
Gre
On 24 января 2009 01:31:50 Herbert Xu wrote:
>
> 2) The highmem primitives we use are currently softirq only. We
> could make them work for hardirq as well, but because of 1) we
> didn't.
>
Could you point to example of such primitive in code under crypto?
Thank you!
signature.asc
Description:
Andrey Borzenkov wrote:
>
> As I can understand, user context requirement is due to potential for
> setkey to sleep (although it appears, that currently the only module
> that can sleep is shash which is calling kmalloc with GFP_KERNEL). Is it
> correct?
Yep.
> But where is the difference bet
According to Documentation/crypto/api-intro.txt:
DEVELOPER NOTES
Transforms may only be allocated in user context, and cryptographic
methods may only be called from softirq and user contexts. For
transforms with a setkey method it too should only be called from
user context.
As I can understand
