2009-01-23 19:29:53

by Andrey Borzenkov

[permalink] [raw]
Subject: Clarification of allowed context for crypto routines

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


Attachments:
(No filename) (647.00 B)
signature.asc (197.00 B)
This is a digitally signed message part.
Download all attachments

2009-01-23 22:31:57

by Herbert Xu

[permalink] [raw]
Subject: Re: Clarification of allowed context for crypto routines

Andrey Borzenkov <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2009-01-24 05:15:19

by Andrey Borzenkov

[permalink] [raw]
Subject: Re: Clarification of allowed context for crypto routines

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!


Attachments:
(No filename) (277.00 B)
signature.asc (197.00 B)
This is a digitally signed message part.
Download all attachments

2009-01-24 09:32:49

by Herbert Xu

[permalink] [raw]
Subject: Re: Clarification of allowed context for crypto routines

Andrey Borzenkov <[email protected]> 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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

2009-01-27 18:01:13

by Andrey Borzenkov

[permalink] [raw]
Subject: Re: Clarification of allowed context for crypto routines

On 24 января 2009 12:32:45 Herbert Xu wrote:
> Andrey Borzenkov <[email protected]> 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 :)


Attachments:
(No filename) (1.24 kB)
signature.asc (197.00 B)
This is a digitally signed message part.
Download all attachments

2009-01-28 03:08:08

by Herbert Xu

[permalink] [raw]
Subject: Re: Clarification of allowed context for crypto routines

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~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt