Clarification of allowed context for crypto routines

Clarification of allowed context for crypto routines

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 667 bytes --]

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, 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?

But where is the difference between hard and softirq contexts? I fail to 
see any technical reason for this requirement.

Thank you!

-andrey

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Clarification of allowed context for crypto routines

[Herbert Xu]

Andrey Borzenkov <arvidjaar@mail.ru> 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 between hard and softirq contexts? I fail to 
> see any technical reason for this requirement.

The reasons are two-fold:

1) Crypto operations are so slow in general that if you did them
in hard IRQ context it would just be wrong;

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.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Clarification of allowed context for crypto routines

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

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!

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Clarification of allowed context for crypto routines

[Herbert Xu]

Andrey Borzenkov <arvidjaar@mail.ru> 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?

Grep for kmap under crypto.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: Clarification of allowed context for crypto routines

[Andrey Borzenkov]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

On 24 января 2009 12:32:45 Herbert Xu wrote:
> Andrey Borzenkov <arvidjaar@mail.ru> 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?
>
> Grep for kmap under crypto.
>

I checked and

- all usage is kmap_atomic; which implies it should be technically safe 
(not advisable) to use in interrupt context as well

- as far as I understand, if it could be kmap() that could sleep, it is 
unsafe to use in tasklet anyway?

Please bear with me. The problem with kernel is lack of any 
comprehensive documentation; so almost the only way to learn is by 
example - get code that is known to work and has at least /some/ 
documentation; and assume that what it does is correct. In this case 
incomplete or misleading documentation leads to adopting incorrect usage 
lately ... in this case I do not argue about code under crypto; but 
rather try to learn how and when I can safely use this code in my 
driver.

So I still miss difference between interrupt context and bottom half 
(i.e. tasklet) that is made in documentation. Sorry :)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Clarification of allowed context for crypto routines

[Herbert Xu]

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 softirq context.  Adding support
for hardirq context can be done by using another two slots but
that would mean adding another conditional branch in the code path.

As it stands I have not seen any convincing use cases that would
justify this.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt